BOOT is a command, not a config property, so the = sign is not needed (and gets included in the filename, if that could be considered a parsing error). The part about booting drive A: is weird, though.
Also, if you don't mount a drive or specify a path for the image filename, it must be located in the default directory, which is typically where DOSBox is installed.
If you look at the file in some editor program, does it start with "PCjr Cartridge image file", the "PCjr" part being particularly important for DOSBox to identify the file as a PCjr cart image.
Pardon me for reviving this discussion but I'm having a similar problem, and I think it's the same game (Demon Attack).
I've opened the .JRC file in a hex editor and herein lies the problem... the header is different than in ripsaw's post. It is 128 bytes of plain text (padded with nulls at the end) and goes like this:
1Filename: E600.bin 2Created: 2007-12-03 20:45:08 3Desc: PCJRCART v1.1 ROM Extension dump 4Start: E600:0000, len 0xA000
Meaning that it was probably dumped using PCJRCART by Mike Brutman. PCJRCART seems to generate a different header than JRipCart does - the latter creates 512-bytes headers that indeed start with "PCjr Cartridge image file" (format spec included with the program).
So in effect there are (at least) two different .JRC file formats, and maybe DOSBox supports just one of them.
Perhaps it's possible to manually (or programmatically) create the JRipCart-style header and use it in place of the old one... in fact I'm going to try just that, but are there any plans to support this other format in future DOSBox versions?
However, there's a difference - with the 128-byte header, it hangs after the "Booting from drive A:..." message. Without the header (raw data), it shows the same message but doesn't hang - it just drops right back to the command prompt.
Status window messages are the same in both cases, by the way...
1Loaded disk 0 from swaplist position 0 - "DEMONAT3.JRC" 2Loaded disk 1 from swaplist position 0 - "DEMONAT3.JRC"
Ok think these are indeed different headers, try a 512 bytes header with the string "PCjr" at its start. Don't see more stuff we're reading from that. The following bytes (start of rom) should be 0x55 0xaa btw.
I actually tried it before I made my previous post, but that didn't even get to the "booting" message before it froze - turns out I simply screwed up the byte order in the segment address... should've paid attention to that spec file more closely 😀
I have jrc cartridge images of Demon Attack and Microsurgeon, and they used mbrutman's 128byte format. I used wd and ripsaw's advice and it worked for Demon Attack but Microsurgeon fails to load at all. Both seem to use offset E600 and I gave them identical headers with just that and PCjr.
I looked at the IMAGIC cart dumps and deduce that they are 16K ROMs at segment E000h but with duplicate address decoding (mirroring) at segment E600h. I think both Demon Attack and Microsurgeon have the same mirrored address decoding, but only Microsurgeon relies on it. The existing dumps appear to not adequately represent the mirroring, and have the 16K ROM bank repeating several times (accounting for the unusually large image size) but not at the segments needed by the game code.
It is possible to reorganize the existing dumps to at least simulate the necessary mirroring. Start with a jripcart 512-byte header (can take one from another image and modify it) with the ROM segment at E000h (bytes 00h E0h at offset 1CEh in the header). To the header append the first 16K (16384) bytes of the existing dumps following their 128-byte header. Then append 8K (8192) zero bytes followed by a repeat of the same 16K bytes appended after the header. This configuration places the 16K ROM bank at segment E000h and again at segment E600h that the game code requires.
Note that Microsurgeon needs a joystick, probably with timed=true and low cycles.
I looked at the IMAGIC cart dumps and deduce that they are 16K ROMs at segment E000h but with duplicate address decoding (mirroring) at segment E600h. I think both Demon Attack and Microsurgeon have the same mirrored address decoding, but only Microsurgeon relies on it. The existing dumps appear to not adequately represent the mirroring, and have the 16K ROM bank repeating several times (accounting for the unusually large image size) but not at the segments needed by the game code.
It is possible to reorganize the existing dumps to at least simulate the necessary mirroring. Start with a jripcart 512-byte header (can take one from another image and modify it) with the ROM segment at E000h (bytes 00h E0h at offset 1CEh in the header). To the header append the first 16K (16384) bytes of the existing dumps following their 128-byte header. Then append 8K (8192) zero bytes followed by a repeat of the same 16K bytes appended after the header. This configuration places the 16K ROM bank at segment E000h and again at segment E600h that the game code requires.
Note that Microsurgeon needs a joystick, probably with timed=true and low cycles.
Game seems to work now. To visualize how the ROM should be :
Header - 512/$200 bytes
Game Code - 16384/$4000 bytes
Zero Filler - 8192/$2000 bytes
Game Code - 16384/$4000 bytes
Demon Attack works fine with just the header and the game code with no filler or repeats.