PCem cassette support and register monitor

[voidstar]

A few months ago, I wrote a game for the PET system (6502 processor), testing it with the VICE (emulator) and running it on my physical PET machine.

I've since ported that game to the TRS80 and Apple ][. I'm now working on an x86 port. With VICE I was able to emulate loading my game from a tape (cassette). I wanted the same experience on the x86, as the original IBM PC 5150 did support a cassette drive (the port was right next to the keyboard!). I tried 86BOx, but... that failed.

So I was excited to see PCem supported loading the original PC-DOS diagnostic program from the ROM C1.0 BASIC!! load"ld it worked!

Now it took me some work to figure out how to compile my C code for the 16-bit real-mode x86. For 6502, I used cc65. For z80, I used z88dk compilers. For the x86, I initially tried TurboC under DOS 6.x, but I refused to convert all my files to 8.3 conventions. Fortunately, I found WATCOM C 1.9 did all that I needed. Then it was on me to learn the DOS INT 16, INT 10, etc. for various system calls to make the game work.

In theory, any (true) .COM file should be loadable by cassette. They all start with like an EB or E9 opcode (some jump instruction) and get loaded at offset 0x100 (something about a hold-over from the original CP/M having a 256 byte header, which I think was the space to support things like command line arguments when invoking your executable?).

So far in PCem, I haven't quite yet figured out how to load anything besides that IBM diagnostic program in the cas1.cas file. For that matter, I tried to write a BASIC program, do SAVE"test reboot, then do LOAD"test and that didn't work either.

That's fine. I can still plop my .COM to a PC-DOS 2.10 image and run it there - and it does work. And the only reason using PC-DOS 2.10 instead of PC-DOS 1.0 is because WinImage doesn't make a proper single sided 160KB image. But I trust the theory that y .COM could be loaded by a cassette on a physical original IBM PC 5150.

If anyone has notes on maybe why the ROM C1.0 (cassette) BASIC SAVE/LOAD aren't working for me (in PCem), would appreciate it! (86BOX makes some simulated cassette data noises, but doesn't actually do anything at all)

ALSO - I'm curious on any x86 register monitor. I know that's quite hard to do (and maintain emulator performance), building a protocol to export all the CPU states out. But I will say, the TRS-80 emulator had a nice memory and register state monitor. Specifically, I'm curious on the register changes that the ROM BASIC is doing (for like SEG DEF and POKE commands - which in BASIC are interpreted and doing a bit more than what you might think under the hood). Is there a separate build of PCem to support this idea of a machine-state monitor?

LASTLY.... As a capability suggestion: in the VICE emulator, I can drag-and-drop my .COM binary or .TAP tape recording right into the VICE (Commodore emulator) and it automatically does what is necessary to execute that code. (for .TAP its initiating a LOAD command, for .COM it's similar but loads via a stream from the file). It's kind of a cheat, and I understand sort of awkward on the IBM PC side - but if one were booted to the ROM BASIC, it would make it a little more seamless to just drag-drop a .COM and go. [yeah, I confess to selfishly just wanting a way to deploy a binary, and have it essentially auto-started for other people who want to check it out -- which is a workflow that VICE supports for just tossing in C64 ROMs, but for example the AppleWin emulator doesn't ]

My game info is at
www.destinyhunter.org
My 11-year old daughter came up with the story, based on a dream she had. It was my own doing for trying to realize it on the oldest hardware I could think of.

Cheers,
voidstar

[omarsis81]

cassette format is only read only - the user who created it, JohnElliott worked on a save function but it wasn't commited by Sarah into PCem
you can read more here and get some info
http://pcem-emulator.co.uk/phpBB3/viewt ... 98&p=11926

[voidstar]

Thank you!! That clarifies it's not just user error on my part.

And to be fair, I didn't verify if SAVE function works in the VICE (Commodore) emulator. To make my audio cassette of my PET program, I used a physical PET to make the recording -- so it's authentic timing (an awful 50 bytes per minute, takes 9 minutes to store 32K).

I can get the rationale for the load only, especially with the advent of those SD floppy disk adapters.


And I think I get the FAR pointers in C and corresponding segment-prefix opcodes now, all good.


Still, it would be kind of cool to drag and drop .COM files into PCem ROM BASIC and have then somehow auto-loaded. As one specific example, one of my favorite DOS games (decades-decades ago) was Montezuma's Revenge. Sure, the DOS port was probably the worst of the versions Though it's odd to me how dependent we've become on OS's. But I'm thinking purely like arcade-games that just communicate with the keyboard and display -- no network or drives, the program strictly lives within the CPU and RAM (just such a program does need to be loaded from somewhere - be it a ROM like those arcades, a cassette drive that the BIOS knows how to communicate with, or in the case of an emulator -- have it magically CTRL-V'd in from a data stream).

[omarsis81]

I think that with "taptools" you can create a cassette image to use in PCem, however I believe that wasn't truly x86 experience. I can't think of any game commercially released in cassette or the IBM PC

[JohnElliott]

I'd have liked to implement save support, because then I'd have been able to load ASCII listings into cassette BASIC and save them in tokenized form. But I couldn't get it to work, because saving didn't work after loading (WIP patch is here, if anyone wants to try and revive it).

I don't know if BASIC will directly execute machine code from cassette. It may be necessary to create a BASIC loader program that loads your machine code from cassette and jumps to it.

[voidstar]

There were apparently only about 6 actual IBM PC programs on cassette:
- 4 versions of IBMs own diagnostic tool
- 1 alleged typing tutor (that maybe was actually written for the Apple, but worked in IBM BASIC- so when sold, Microsoft just stuck a different label on it- per rumors, no one online has fessed up to actually having a copy of this),
- 1 rumored game that let you also save your progress on a cassette.
Here is a video of Galaxy (the game that was on cassette), but I don't think the video is the IBM PC version
https://www.youtube.com/watch?v=BBMuhYGZGpo


And, apparently, the cassette support for the IBM PC was more popular over in Russia (due to less $$ to afford disk drives = more IBM PC base models). And as far as Data (Love Letters, Small Business Accounting): if you're already booting to PC-DOS or MS-DOS, any editor you used probably wouldn't support saving to cassette (VisualCalc on IBM PC, which apparently still runs on modern PCs -- didn't dig into it enough to see if it has an option to save data to cassette: http://www.bricklin.com/history/vcexecutable.htm )


Per this article (2019):
https://forum.winworldpc.com/discussion ... the-ibm-pc
"The IBM Advanced Diagnostics cassette consists of a two part program. The first is a BASIC loader stub. The second is a binary machine language program that the stub loads." Then goes on to explain that yes, you had to load the loader stub first, pause your tape, RUN the loader, then proceed the tape to load the actual program. Yuck.

When I ran the Diagnostic program, I thought it was just slow at assessing all the PC hardware - like actually scanning all RAM to determine how much, etc. But no, I misunderstood and didn't realize the RUN was actually resuming the tape loading (didn't notice in the console window the additional motor ON) - so the LONG DELAY is just loading the rest of the program from the tape.

And if you do LIST after the first load (see attachment), indeed all that first program is, is 112 byte loader to load the rest of the program from the tape (pay attention to the comments at the top of the program, it has a WR variable to control whether you LOAD or SAVE a copy -- so it can become a "bootsaver" with just a few POKE adjustments).



Did the loading fail due to the "tape" running to the end, and no virtual rewind, so the motor couldn't proceed to save anything? I noticed with LOAD"ldcass run the DIAGNOSTIC - if you then exit, you can't load it again until a reset of the emulator (no way, that I can tell, to rewind the tape back to index 0).

And yes, being able to save little BASIC programs would be handy (as I don't think the emulator has any CTRL-V, copy/paste? in VICE it has an Edit|Paste that can insert BASIC programs into the memory, and in AppleWin you can do CTRL-INSERT to paste {it's kind of fun to watch it "speed-type" a BASIC program in}).


Interesting, there is no "2-stage" process on the Commodore PET for loading binaries (even on the physical machine). There is a BASIC component (a SY call to the initial address of the program, around 0x400)

[ruben_balea]

The PC-DOS 1.x images have a small problem on the boot sector, they say "7-May-81" but "May-81" starts at offset 0x0B in place of the BIOS Parameter Block used by 2.x and further PC-DOS versions.
This causes incompatibility with Winimage and also with any Windows version and I think most MS-DOS versions too.
I have created a modified 160KB image that can be edited with Winimage and then used within PC-DOS 1.00, I didn't do too much testing but it seems to work: https://drive.google.com/file/d/1h2vdGP ... sp=sharing
Also the RAR file contains the original boot sector and the modified one, that way you can edit the image and later use a HEX editor or something to insert the original boot sector if you want to make it look more authentic

I didn't test it on the original PC but it should work, I always use the Generic XT machine in PCem (mostly because it can run @16MHz) to boot early DOS versions and access small disk images because AT and later BIOSes seem to have trouble with floppies under 360KB.
I think the SYS command expects the original boot sector but anyway to create bootable images it's better to start with a blank floppy image and use format b:/s to create an "empty" bootable floppy.
Note: The format / s command works like in later versions of DOS, but it won't display anything related to system files, it just takes longer than a basic format.