Announcement

Collapse

Forum Rules and Etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Rule 1: Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Rule 2: Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Rule 3: Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


Rule 4: "PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Rule 5: Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

IBM 5150 Cassette Generation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by Shadow Lord View Post

    Actually this is exactly what I was suggesting/asking for. Yes the file will be large by 5150 standards but by Win 10 standards? Nah The bigger hurdle (vs. file size) IMHO is getting people to install the interpreter just to run one script. A big self contained EXE is a much easier sell...
    https://github.com/MasonGulu/ibm-xt-...eases/tag/v1.0

    Here. I've compiled it using https://pypi.org/project/auto-py-to-exe/.

    I had to fight windows defender for it to not delete the files because it detects them as a trojan. I really don't see why this is very preferable, but once I fix asciiwrite I'll post another release with updated executables.

    Comment


      #17
      Originally posted by ShreksHellraiser View Post

      https://github.com/MasonGulu/ibm-xt-...eases/tag/v1.0

      Here. I've compiled it using https://pypi.org/project/auto-py-to-exe/.

      I had to fight windows defender for it to not delete the files because it detects them as a trojan. I really don't see why this is very preferable, but once I fix asciiwrite I'll post another release with updated executables.
      Thanks. This makes it so much easier to experiment with. As for Defender you can tell it to ignore a particular file or directory. Anything dropped in that directory will not be scanned.

      I look forward to the new version with the corrected bugs.
      Current Wish List: 1. IBM 7531 Industrial Series PC 2. NEC MultiSync XL (JC-2001) Monitor 3. MicroSolutions UniDOS card 4. Compaq 14" VGA CRT Monitor (the one that came with the SystemPro). 5. Stacker HW CoProcessor Board MCA BUS. If you have any of the above for sale please PM me. Thank you!

      Comment


        #18
        I have updated asciiwrite.py, in my limited testing it appears to work fine now. The issue was that for some reason Basic ASCII listing files are split into distinct blocks of data, each with their own header/lead in.

        I have also updated binwrite.py, it's now around 17% faster at generating the file by reducing the amount of bitwise operations taking place.

        I've added a new script, cgaprocessing.py. I recommend against using it, but if you decide to it'll take an image (that is in 4 colors matching one of the palettes) and turn it into raw binary data to be loaded into CGA ram.

        Compiled binaries will be a little while. I don't have access to a windows machine now, I should get it back in a few weeks.

        Comment


          #19
          Cool, I'd like to try this out as well, but I'm going on travel for a few weeks.

          My understanding is that any .COM file is a real-mode single segment program. For the most part, I think they can be loaded into any segment -- and I think typically they start at 0x100 offset into that segment (old CP/M convention? although they don't really have to -- studying a few .COM files, they all seem to start with some jump instruction). The "single segment" limit is why all .COM files are under 64KB.

          Some EXE files are actually .COM files - a "real" .EXE file always starts with "MZ". But if you see an .EXE file that is under 64KB and doesn't start with "MZ", it is probably actually a .COM file. Plus recall that DOS (2.x and 3.x I think) included EXE2BIN utility that did some adjustments these kinds of EXEs to make them into proper .COM files. Turbo Pascal 3 (for example) compiles into .COM files, so it is limited to make 64KB programs (but I recall they supported OVL/overlays to effectively make larger programs). So it all depends on what compiler a developer used for a certain EXE or COM (and I suspect in the early days, some tools just made these "exe files that are actually com").

          There is no protected-mode build of EXE2BIN - not that such a thing is really needed anymore. But I always wanted to do a project where I imagine some Python script could effectively replicate what EXE2BIN did -- there was nothing real magical about it, it just did a few byte adjustments to an EXE and made it into a .COM file. Since MS-DOS is on github now, I once studied the EXE2BIN assembly (and I think I was in some situation where Watcom C was making a real-mode EXE, but I didn't have EXE2BIN available to convert it to COM -- there were various ways to deal with all that, but I just recall once being in a situation where I wish I had a modern protected-mode version of EXE2BIN {and that being kind of a perfect learning/training job for Python to do).


          I do have a 5150 with cassette port, and I studied that IBM Diagnostic program for a bit. It's loaded in two stages - but if you LIST the program during the first stage, you understand why: the first stage has nothing to do with the IBM Diagnostic program itself, it is just loading a little "pre-loader" to load the second stage into memory (i.e. the BASIC program is a bunch of DATA codes to literally load an assembly program into memory, which is used to invoke the 2nd stage of loading). An associate studied that first stage loader for a bit (decoded assembly), and we concluded that with very little adjustment (a few bytes of opcodes), that same loader could probably be used to load any .COM program from tape (in the same two-stage process). Even if you over-estimate the size of your .COM program, the consequence would it just takes a little longer to load your program from the tape (a full 60K program might take like 2-3 minutes to load from a tape).



          Then it occurred to me, a Python script like you described should be possible: basically take any .COM binary and convert it into a sequence of DATA codes in a BASIC program, to just POKE that binary directly into RAM (probably at 0x100 offset, and pick a segment). But it would be limited in size, since each BASIC encoding of the data is like 4 or 5 bytes? So the largest binary you could encode this way is maybe 12K.

          The smallest .COM I'm aware of (aside from 704K.COM and maybe the Adlib SOUND.COM?) is a small VGA demo program I found calls ORBIS that is about 3K or 4K - so that's a perfect candidate to experiment with (well, if you have a VGA - I found a working 8-bit ISA VGA for my 5150). But my own game, destinyhunter.org compiled into ~32K .COM file, and wouldn't fit in that method. So I think an alternative to support that would be to have a Python script that generates something like that IBM Diagnostic 1st-stage BASIC program.

          I've attached my transcribed version of that IBM Diagnostic loader (again, it is a pre-loader the POKEs in some DATA that is code -- then you run that code, and THAT invokes a loader that reads the 2nd stage of the program from tape and puts it in the appropriate offset of the current segment -- I'm not sure how large the actual IBM Diagnostic program is, but we could experiment by finding a smaller .COM than whatever that size is).


          Gotta run for a couple weeks - but I think it would be pretty funny to "go backwards" and start storing any arbitrary .COM binary back onto tape (typically it's the other direction - we want to preserve tape content back into disk images). Just brute force auto generating the BASIC code that DATA sequences the binary is one way -- just again, I think it'll be limited to ~12KB binaries (estimating 60K / 5). But I think ancient games like DigDug, Paratrooper, MoonPatrol, Allycatz (i.e. old .COMs that don't have any File I/O or disk operations) would be candidates (and my own game DHUNTER.COM ).


          Attached Files
          IBM 5110 ['78], PET 4016 ['80], C64 ['82], IBM PC 5150B ['84]. A retired SysOp, creator of destinyhunter.org, VUC, ANT

          Comment


            #20
            Originally posted by voidstar78 View Post
            Cool, I'd like to try this out as well, but I'm going on travel for a few weeks.

            My understanding is that any .COM file is a real-mode single segment program. For the most part, I think they can be loaded into any segment -- and I think typically they start at 0x100 offset into that segment (old CP/M convention? although they don't really have to -- studying a few .COM files, they all seem to start with some jump instruction). The "single segment" limit is why all .COM files are under 64KB.

            Some EXE files are actually .COM files - a "real" .EXE file always starts with "MZ". But if you see an .EXE file that is under 64KB and doesn't start with "MZ", it is probably actually a .COM file. Plus recall that DOS (2.x and 3.x I think) included EXE2BIN utility that did some adjustments these kinds of EXEs to make them into proper .COM files. Turbo Pascal 3 (for example) compiles into .COM files, so it is limited to make 64KB programs (but I recall they supported OVL/overlays to effectively make larger programs). So it all depends on what compiler a developer used for a certain EXE or COM (and I suspect in the early days, some tools just made these "exe files that are actually com").

            There is no protected-mode build of EXE2BIN - not that such a thing is really needed anymore. But I always wanted to do a project where I imagine some Python script could effectively replicate what EXE2BIN did -- there was nothing real magical about it, it just did a few byte adjustments to an EXE and made it into a .COM file. Since MS-DOS is on github now, I once studied the EXE2BIN assembly (and I think I was in some situation where Watcom C was making a real-mode EXE, but I didn't have EXE2BIN available to convert it to COM -- there were various ways to deal with all that, but I just recall once being in a situation where I wish I had a modern protected-mode version of EXE2BIN {and that being kind of a perfect learning/training job for Python to do).


            I do have a 5150 with cassette port, and I studied that IBM Diagnostic program for a bit. It's loaded in two stages - but if you LIST the program during the first stage, you understand why: the first stage has nothing to do with the IBM Diagnostic program itself, it is just loading a little "pre-loader" to load the second stage into memory (i.e. the BASIC program is a bunch of DATA codes to literally load an assembly program into memory, which is used to invoke the 2nd stage of loading). An associate studied that first stage loader for a bit (decoded assembly), and we concluded that with very little adjustment (a few bytes of opcodes), that same loader could probably be used to load any .COM program from tape (in the same two-stage process). Even if you over-estimate the size of your .COM program, the consequence would it just takes a little longer to load your program from the tape (a full 60K program might take like 2-3 minutes to load from a tape).



            Then it occurred to me, a Python script like you described should be possible: basically take any .COM binary and convert it into a sequence of DATA codes in a BASIC program, to just POKE that binary directly into RAM (probably at 0x100 offset, and pick a segment). But it would be limited in size, since each BASIC encoding of the data is like 4 or 5 bytes? So the largest binary you could encode this way is maybe 12K.

            The smallest .COM I'm aware of (aside from 704K.COM and maybe the Adlib SOUND.COM?) is a small VGA demo program I found calls ORBIS that is about 3K or 4K - so that's a perfect candidate to experiment with (well, if you have a VGA - I found a working 8-bit ISA VGA for my 5150). But my own game, destinyhunter.org compiled into ~32K .COM file, and wouldn't fit in that method. So I think an alternative to support that would be to have a Python script that generates something like that IBM Diagnostic 1st-stage BASIC program.

            I've attached my transcribed version of that IBM Diagnostic loader (again, it is a pre-loader the POKEs in some DATA that is code -- then you run that code, and THAT invokes a loader that reads the 2nd stage of the program from tape and puts it in the appropriate offset of the current segment -- I'm not sure how large the actual IBM Diagnostic program is, but we could experiment by finding a smaller .COM than whatever that size is).


            Gotta run for a couple weeks - but I think it would be pretty funny to "go backwards" and start storing any arbitrary .COM binary back onto tape (typically it's the other direction - we want to preserve tape content back into disk images). Just brute force auto generating the BASIC code that DATA sequences the binary is one way -- just again, I think it'll be limited to ~12KB binaries (estimating 60K / 5). But I think ancient games like DigDug, Paratrooper, MoonPatrol, Allycatz (i.e. old .COMs that don't have any File I/O or disk operations) would be candidates (and my own game DHUNTER.COM ).

            I'm gonna break this up into smaller sections as I respond to it.

            .COM Programs
            I've recently been getting into writing my own dos programs, primarily in .COM format. You're correct about them being loaded 100h bytes into the segment, I'm not sure why that's the case, but because of that all absolute jumps, labels, and locations of memory are offset 100h bytes from the start of the file. There's nothing in those 100h bytes as far as I'm aware of, but since the program was compiled with starting at 100h in mind, it will not function correctly at any other offset.

            EXE2BIN
            It's possible that EXE2BIN would go through an "untrue" .EXE file, and just adjust these addresses to be in relation to 100h. This would be possible, and relatively easy, to implement in a python script. Though this also requires some kind of x86 interpreter that can recognize what values are absolute addresses, which is above my comfort level currently.

            Cassette Diagnostics
            Since no commercial program was ever made available on cassette, other than IBM Cassette Diagnostics, I've done a fair amount of digging around with it. I actually at one point had a python script to turn a perfect tape audio file back into binary, and I spent a fair amount of time digging through that and comparing it to the information available on http://fileformats.archiveteam.org/w..._data_cassette. It's actually incredibly accurate, and off the top of my head I can't remember any errors the site had.

            The BASIC loader program is overly complex for what's needed. It could be replaced by a much shorter loader program like this, as BASIC includes statements to load binary memory dumps off cassette. All this would require is an additional ~10 second header placed before the actual binary data (what's already on the tape). The only reason this wouldn't work is if the program is larger than 64k. There is no way this is even close to 64k, a 64k tape image is at least 8 minutes long from my testing.
            Code:
            10 DEF SEG = &h1000  REM This sets the active segment (DS/CS) to 1000h
            20 BLOAD "LDCASS",0  REM This loads a binary image called "LDCASS" at offset 0
            30 O = 0: CALL O   REM You cannot call an immediate, so you have to set a variable to the address. This moves IP to the value in O and sets the CS to the same as the SEG set earlier.
            Though they place the loader program in ram at offset 03F5h and use CLEAR to free up memory so that this program can be loaded into a computer with 64k of ram.

            Arbitrary .COM files on tape
            Under DOS this would be possible, if you ask DOS to allocate enough ram for it, load the image off tape into the ram DOS allocated for you, and then moved execution there. You could also instead just use existing DOS programs to save or load files from tape.

            Under Cassette Basic this MAY be possible. Each .COM file would need inspected, looking for any DOS interrupts or functionality being called upon. DOS provides more than just file handling, it also handles general screen I/O and string input. For games that don't require that, and don't use int 20h, int 21h, or any other DOS interrupts they should work fine, but they won't exit correctly, as to return from a machine language program in BASIC you must preserve the stack and then do a RETF once your file is done executing.

            My scripts
            I think you misunderstood my scripts. There's two of them, one of which is for ASCII text files, the other for binary files, whether executable, data, or anything else. The ASCII script generates a header which identifies itself as an ASCII basic listing. The file itself is then written in individual 256 byte blocks, any newlines are fixed, and the first byte of each block is either 0 or the amount of bytes remaining. The BIN script generates a header which identifies itself as a memory dump, and the file itself is then written in a series of continuous 256 byte blocks of just data. You can remove the header and then have perfectly valid data to load using the BIOS interrupts, which is what I've been doing for my image viewing stuff.

            Thank you for the interest in my scripts, and I hope you find use and enjoyment from them. If you have any questions just let me know.

            Comment


              #21
              The offset of 100h in .COM files leaves room for the PSP goodies, including default FCBs and the command line tail buffer. This was done to make the conversion from CP/M .COM files as painless as possible. You'll even note that the PSP has a hook so that you can invoke the DOS API by putting the function in CL and doing a jump to 0005h, just like CP/M-80. Similarly a .COM program can terminate by jumping to 0000h, just like CP/M-80.
              Reach me: vcfblackhole _at_ protonmail dot com.

              Comment


                #22
                Originally posted by ShreksHellraiser View Post
                Since no commercial program was ever made available on cassette, other than IBM Cassette Diagnostics,
                Actually this is not accurate. Aside from the two diagnostic programs (regular and advanced diagnostics) the program Typing Tutor was also available for purchase on tape. You can find a discussion on it here. There is a question as to if the program was actually ever produced on tape but marketing material was definitely out there. There is also mention of a game that ran off of disk but allowed you to save your data on to tape.
                Last edited by Shadow Lord; August 23, 2021, 07:27 PM.
                Current Wish List: 1. IBM 7531 Industrial Series PC 2. NEC MultiSync XL (JC-2001) Monitor 3. MicroSolutions UniDOS card 4. Compaq 14" VGA CRT Monitor (the one that came with the SystemPro). 5. Stacker HW CoProcessor Board MCA BUS. If you have any of the above for sale please PM me. Thank you!

                Comment


                  #23



                  I finally got time to try out these Python scripts. SHORT VERSION: They worked


                  So here goes my story...



                  I was trying to understand what happened to Wheel of Fortune 1. We still enjoy playing Wheel of Fortune 2, as it works with CGA and 256KB RAM systems. I'm still trying to understand how, by 1988, WOF2 was still a CGA game. WOF3 finally went EGA, but still neglected any Adlib/SB support (and anyhow runs too slow for my 4.77mhz, so we stick with WOF2).

                  Apparently there WAS an earlier WOF from 1987, from Sharedata - with roughly the same gameplay/style as WOF2, but even WORSE (more orange) graphics. So, WOF2 is the best.


                  And then.... I came across what I will call WOF0. The "original" 1984 "text-based" WOF written by Phil Katz (yes, of PKZIP). And it was written in BASIC.


                  So then it hit me: what a perfect time to test this BASIC to WAV conversion Python script. Which, incidentally, I knew this WOF0 wouldn't run from ROM BASIC -- because it references an external file to get all the categories and puzzles. This .BAS was intended for use by BASICA.COM. Still, it is basically just a text file, so I decided to try it out.


                  So here we go:
                  (and yes, I installed Python 3....)


                  F:\IBMPC\GAMEs\WHEEL_OF_FORTUNE\WOF0>asciiwrite.py fortune.bas test.wav
                  255 bytes written.
                  510 bytes written.
                  ...
                  7650 bytes written.
                  7905 bytes written.
                  End of file reached.
                  8103 bytes written. <-- this checks out, that's the size of the BAS file.
                  (this resulted in a 11.5MB WAV file)


                  Then, while I was at it, I also decided to try the same experiment I did with 5150caxx and use the other script to write PTROOPER.COM.

                  (to keep example simple, I previously copied the PTROOPER.COM file into this same WOF0 working directory)

                  F:\IBMPC\GAMEs\WHEEL_OF_FORTUNE\WOF0>binwrite.py ptrooper.com ptrooper.tap 0 0
                  Silence finished at 0:00:03.496636
                  Basic header finished at 0:00:04.809484
                  Written bytes: 256
                  Written bytes: 512
                  Written bytes: 768
                  ...
                  Written bytes: 16128
                  Written bytes: 16384 <-- ok, checks out, same size as the .COM file
                  Finished at 0:01:48.548295
                  (this resulted in a 7.8MB WAV file)



                  I then brought the TRS-80 cassette recorder to the (modern) PC. Double checked things, it was recording the WAV files out of the headphone jack just fine.


                  SIDEBAR:
                  krebizfan

                  While I was at it, I decided to also record the two WAV files archon11k25.wav and bdash11k25.wav that were referenced here
                  Basically, quick story on this is that neither of these two WAVs worked for me. ROM BASIC just said "Device Error" when trying to load. When I inspected the raw data using 5150caxx, it just loaded a 256 byte header and said there was some CRC error (and this header didn't look quite right to me). Are these PCjr-only games? (although I wouldn't expect the ROM BASIC for the PCjr to not really be different - in terms of how BASIC loads and saves; I'd understand if the game didn't run, but it still should have loaded something). Anyhow, no luck for me on these particular WAV files.



                  Results:

                  (#1 PTROOPER binary)
                  So... I tried loading PTROOPER first, from the WAV recording created by binwrite.py. I was bummed because at first it didn't work. I even loaded the binary package using 5150caxx, and it reconstructed the .COM just fine. So I felt like the data was there, it was very close.... Then I figured it out: I was loading at offset decimal 100 instead of hex 100 (i.e. should have been loading at offset decimal 256).

                  So, upon creating the WAV using Python, and physically recording it to a tape at 1:1 real time playback.... Then here is what I had to do, to load that binary back using ROM BASIC:
                  def seg=&H2000 ' I just picked a segment, I'm not sure if it really matters which one
                  bload " ",256 ' this is where I went wrong, I was using ,100 instead of ,256
                  (press play on tape, wait for ptrooper.M to be found)
                  A=256 ' set some variable to the starting offset ($100 or &H100 or 0x100 = decimal 256, for most .COM programs)
                  call A

                  Brilliant, this is essentially how we do it on the Commodore PET from '77 (just in the PET the command is SYS instead of CALL).


                  IMG_7263A.jpg

                  Boom! It passed execution to the binary that was loaded into memory, and Paratrooper was up and running via ROM BASIC loaded from a tape. That's a bit exciting, except I have to say that I still like the 5150caxx 32-byte pre-loader a bit better (just avoids having to do a CALL).




                  (#2 fortune.bas)
                  Next I tried the FORTUNE BASIC program that was recorded to the tape via the WAV created by the asciiwrite.py script (sorry, I still call them scripts, not programs :P ).


                  IMG_7162A.jpg

                  And that worked too! I can tell you, for sure I didn't type this ~200 lines of BASIC myself. As expected, it didn't run - LINE 40 works, that's about it. It does an OPEN statement right after that, so the program eventually just times out ("Device Not Found" or something). So that's pretty cool too.

                  Only observation I have is: while loading the BASIC program, the Cassette relay clicked quite a few times - is the program saved in "chunks" of like 500 bytes? Not sure if there was any actual pause in the playback, but I could certainly hear the clicks.


                  IMG_7167A.jpg








                  So that's pretty neat, Python to make WAV files that are recordable and loadable.


                  5150caxx is a little more "seamless" in that it can encode a file directly to tape, pre-fixed with an appropriate "pre-loader" so you don't really have to think about how to load it -- you just do load " ",r and go. And that it runs directly in "real-mode" as a DOS program (essentially use the BIOS ROM as its API for doing the actual audio output). I'm up to about 20 .COM programs recorded to tape and verified reloadable from tape.


                  I guess only one thing left for me to try: will it load using my iPhone as playback instead of that massive TRS-80 tape deck? Need to find a place to host a 10MB WAV file, hmm....

                  EDIT: Answer, yes it does (load when playedback from phone). WAV is hosted here until I'm forced to move it. Don't need a DOS, just x86 it up and go












                  Attached Files
                  Last edited by voidstar78; August 28, 2021, 10:53 PM.
                  IBM 5110 ['78], PET 4016 ['80], C64 ['82], IBM PC 5150B ['84]. A retired SysOp, creator of destinyhunter.org, VUC, ANT

                  Comment


                    #24
                    It looks like Wheel of Fortune is using a BASIC data file. IIRC, BASIC stops the cassette after each data block (256 bytes) is read and restarts the cassette to read the next block once an Input command accesses data in the next block. This works well with classic BASIC programs that do a lot of processing on each record before moving to the next but is quite inefficient with bulk data reads.

                    Boulder Dash and Archon are IBM PC CGA games. Other than Boulder Dash needing 128K, they seem fairly standard. The WAV should have two files: the short BASIC stub that loads the longer game file. I am not sure what went wrong.

                    Comment


                      #25
                      I see, ",B" loads in the 256 blocks fashion? (as opposed to something that's ",M") None of the BASIC ROM assembly code was ever released, is that right? (was curious to verify the load code)



                      AND... I got BDASH and ARCHON working! I loaded them using the phone instead of the TRS-80 tape deck.


                      I've saved and loaded-back (and ran successfully) ~20 .COM programs now, using 5150caxx. So I don't think there is a real issue with that process, or the tape deck equipment, or the tapes themselves (new tapes).

                      I was wondering why the Python generated WAVs were so much larger (~8mb) than the BDASH and ARCHON WAVs (~2mb).


                      If the file details are correct, BDASH and ARCHON are 88kbps bitrate. (worked playing out of iPhone headphone jack into EAR jack of the 5-pin DIN cassette port -- but you have to manually pause the playback after the initial ".B" loader is finished, then do "run" and then resume the playback {luckily the player shows the little blank between these two data streams, to help know where to stop})

                      Whereas the WAVs generated by the Python scripts are reported as 705kbps bitrate. (these worked, playing from modern PC headphone into the MIC jack of the TRS-80 tape deck, then loaded in ROM BASIC from said TRS-80 tape)



                      So, all good. The BDASH and ARCHON programs work a little differently than .COM files (by executing from offset 0 instead of 256 -- which I suppose a true "auto boot loader" would?). But the WAV quality might be insufficient for physical audio tape?



                      EDIT: I don't think Flightsimulator 1.0 from tape will work. Or at least, not at all straight forward. While it can run with 64KB RAM system, the IMG file has a lot of disjointed data streams. We'd have to figure which stream goes into which segment and make quite a custom loader for it. We also have to see if the game accesses the disk at any time after it is loaded, to see if it is dynamically initializing segments at any time -- if it doesn't and it iniitializes all the segments in one go, then there might be a chance.




                      IMG_7273A.jpg IMG_7277A.jpg
                      Last edited by voidstar78; August 29, 2021, 11:20 AM.
                      IBM 5110 ['78], PET 4016 ['80], C64 ['82], IBM PC 5150B ['84]. A retired SysOp, creator of destinyhunter.org, VUC, ANT

                      Comment


                        #26
                        deanimator

                        Shadow Lord





                        I've finished an article and notes to summarize all my "findings" about the IBM PC cassette port.

                        5150: Setting up Tape Deck Connection (because the 5150 can)

                        https://voidstar.blog/5150-setting-u...-the-5150-can/

                        Contents, for future reference

                        Significance of the IBM PC 5150 Tape Support
                        History of IBM PC Cassette Software Support
                        Introduction to the Cassette Port of the IBM PC 5150
                        How to Encode a .COM to Tape Using 5150CAXX.EXE
                        How to Load a .COM that was Saved Using 5150CAXX
                        Using Python to Make Tape Loadable Binaries
                        EXAMPLE 1: Using ASCII (BASIC) [ asciiwrite.py ]
                        Saving WAV to Tape: Using TRS-80 Tape Deck (or similar)
                        To LOAD this ASCII (BASIC) file into IBM PC 5150 ROM BASIC
                        EXAMPLE 2: Using binary [ binwrite.py ]
                        To BLOAD this binary data or program using 5150 ROM BASIC
                        Playing BDASH and ARCHON from WAV (using smartphone)
                        Successful .COM to Tape Conversions


                        (not meant as a historical document, just reference notes on how some of this stuff works in case anyone else wants to try)
                        IBM 5110 ['78], PET 4016 ['80], C64 ['82], IBM PC 5150B ['84]. A retired SysOp, creator of destinyhunter.org, VUC, ANT

                        Comment

                        Working...
                        X