JR-IDE & ZM56 Hack

[alanh]

I'm not 100% convinced decoupling video ram is a good idea yet. I'm seeing some compatibility problems with some software I think is PCJr aware. I'm guessing some software is reading/writing to low memory rather than panning the B8000 window around with the CPU page reg. I'll have to revert the change and retest first.

Since the decoupling is really only saving about 60K after all is said and done, it might not be worth it. I haven't tried tweaking the UMB driver yet. That mod might be worth it to some. It does break cartridge operation, but you could write a simple loader that plays cartridges from DOS in theory.

[Brutman]

The key advantage would be to get operating systems to be able to boot without having to use a device driver to relocate the video buffer. With the 16KB hole filled with real memory jrConfig should be a pleasant memory - the machine would just boot. You could also achieve the same thing by having the BIOS just put the hole in lower memory and telling DOS where to load, which is equivalent to jrConfig. I think the Racore expansion units can do this when the magic switch is set to "PC" mode.

The jrExcellerator fills the memory hole but suffers from the same problem. They provide a switch to enable or disable the feature as needed.

We are cursed. ; - 0

I don't mind the warts on the PCjr - it makes the machine what it is.

[geoffdaddy]

The only wart that kind of bothers me with the jr is the serial port, and using the NMI for keyboard decoding. I was thinking a project to add a keyboard microcontroller to decode the IR and buffer it up and that operates at the normal INT would be nice.

[geoffdaddy]

I'm not 100% convinced decoupling video ram is a good idea yet. I'm seeing some compatibility problems with some software I think is PCJr aware. I'm guessing some software is reading/writing to low memory rather than panning the B8000 window around with the CPU page reg. I'll have to revert the change and retest first.

I guess the big advantage might be no wait stating the low memory. If that worked it could speed up performance quite a bit.

[alanh]

So I've reverted the lower 128K part of the hack. It breaks compatibility with the Sierra Tandy/Jr driver which is what I mostly use my Jr for. I did notice a significant slow down when I did that - especially for long operations like computing 2GB of free disk space. Looking at the schematic the only things that can add waits are the side-car bus, audio chip, and video chip. And without the later selected, it does look like the lower 128K when running off the side-car is full speed. Norton SI and Landmark didn't show a speed-up but I'm guessing that's mostly CPU indicative.

So for now, I'm back to JRCONFIG and on-board lower 128K. I still have the cartridges gated off so that's 128KB of additional upper memory I can pick up for UMB and other things in addition to the 48K that was already accessible in the C segment.

Jamco has the 1Kbit ROMs that will fit in ZM56 unmodified. I'm using a 22v10 (what I had on-hand) handing over the edge of the new socket with the ground pin strapped over. Should be able to be done with a 16V8 too.

[geoffdaddy]

I can't recall from the schematic right now, but I wonder if there's an unused input on that ROM that could be used to switch the memory addressing from the stock to the modded way (while turned off of course)?

[Trixter]

I'm not 100% convinced decoupling video ram is a good idea yet. I'm seeing some compatibility problems with some software I think is PCJr aware. I'm guessing some software is reading/writing to low memory rather than panning the B8000 window around with the CPU page reg. I'll have to revert the change and retest first.

This was common; I've RE'd some PCjr-only versions of software and they're reading/writing 1800 instead of using the page registers with b800 like they're supposed to.