Hello guys! I started playing with the PCjr.
I configured the floppy A to 360 KB and booted with MSDOS 3.3.
It boots fine, but once in the prompt, I change the floppy image, and when I type DIR it keeps displaying the contents of the DOS image. It looks the floppy contents is kept in memory and doesn't refresh.

I also tried with IBM PC DOS 2.1 and the same result. Disk contents doesn't refresh when I change the image.

Format works, but the floppy needs to be of the same size you're formatting it to, otherwise the emulation will return sector not found. This is done because PCem right now stores only one track at a time in memory and then writes back rather than storing the whole floppy image in memory and then saving on emulator closure.

More a limitation imposed by the .IMG format, as it's not possible to represent any of the interim states of the disc while it's being formatted (eg while some tracks are in the new format and some still in the old). Plus there's always the possibility that the user could be formatting a disc with a deliberate mix of formats. PCem simply dodges this minefield by not allowing you to format disc images to a different format.

1) I select the DTK XT clone, with only one drive A as 360k
2) load the image "dos33.img" and it boots fine
3) once in A> I switch the image to "sabot2.img"
4) I run "DIR" and it shows the file SABOT.EXE
everything went OK

now, I do the exact same with the PCjr, but in the step 4, it keeps displaying the COMMAND.COM, which is on the previous disk image.

SarahWalker wrote:More a limitation imposed by the .IMG format, as it's not possible to represent any of the interim states of the disc while it's being formatted (eg while some tracks are in the new format and some still in the old). Plus there's always the possibility that the user could be formatting a disc with a deliberate mix of formats. PCem simply dodges this minefield by not allowing you to format disc images to a different format.

It's even more a limitation of the current PCem code. It stores only one track at a time rather and regularly writes back rather than storing the entire disk at a time. Storing the entire disk at the same time and then saving on close or hard reset would get rid of this limitation. The internal state could then store mixed tracks (and even parameters such as gap sizes, etc. for each track), making it save a mess only if mixed tracks persist until save time. And an "Eject without saving" option could be implemented for each drive to allow the user to eject the image without saving the data, therefore preventing a bad state from carrying over to the image. Also, the save code could then be designed to also not save if it detects that not all tracks have the same layout. And the modifications to the current code structure would be minimal - all that would need to be added would be a save function which would do the work for IMG but be a mere stub with just a "return;" for FDI. The rest would be structurally identical.

Still the second floppy drive doesn't work.
I manage to boot with drive A, but when I insert a floppy in drive B, I switch in DOS to B: and the prompt changes, but when I type DIR, I still get the contents of drive A.
Maybe I need to configure the PCjr internally to recognize the second drive? Or a better guess is that it uses 180kb floppies but PCem only allows 360kb.
Odd, as drive A works fine with the 360kb...
Could you take a look at it when you have some spare time?

PS: also, PCjr came by default with 64kb RAM and only 128kb with an expansion cartridge, currently 128kb is the only option

Battler wrote:Are you sure the BIOS we use even supports more than one drive?

Do you know how to check what BIOS version am I running? Probably by typing some kind of peek/poke in the onboard BASIC?
All I can tell is the the SHA-1 and MD5 for the BIOS I have
SHA-1: 1f5f7013f18c08ff50d7942e76c4fbd782412414
MD5 : c66b49cd7082d1b81442fb2704542401