The Briel Replica 1 plus uses a 27c128 EPROM for its firmware. I have tested doubling the firmware, to a 27c256, and adding a SPDT to pull A14 high/low. You can actually put the firmware in the upper half (or both halves) of a 27c256 without modifcation to the briel, as pin 27 is held high (+5) on the PCB. But by lifting pin 27 (A14) of the 27c256 out of socket, and tying it to that SPDT with gnd/5v (low/high), I am effectively doubling the ROM space available on my machine. Problem is, I could use some guidance on positioning and formatting of the data.
Right now, were I to "black box" it and just guess, I would literally dump the whole memory 0000.FFFF and then correlate the chunks to the EPROM dump. The manual for the R1+ shows a memory location reference, but, I need to correlate the memory ranges as the CPU sees them to the location and format of data within the EPROM.
One curious thing, looking at the schematic of the R1, is it seems the jumper for integer vs applesoft basic is a jumper to ground out A13 from its pull-up resistor. To me this implies the ROM should be cut in half, and the only difference should be integer vs applesoft lite BASIC, but this isn't the case from what I see. Krusader is in the ROM dump in what appears to be little endian format, but it's only in there once. I just enabled applesoft basic via jumper and Krusader isn't available, so it's possible the rom is doubled (i.e. this jumper already selects high/low half of the existing EPROM), but I don't see much or anything repeating. So either I'm mis-reading the schmeatic, there is some other trick going on there, or both.
When I first did the bank switch experiment with A14 on the 27c256 I had P-LAB (Claudio) change the initialization vector to the address for the SD OS. Functionally this would have given a switch that changes the reset button to also launch back into the SD OS instead of woz mon. The problem is that the PIA doesn't get initialized if you jump straight to another program. Uncle Bernie told me via email recently "The PIA initialization in the Apple-1 relies on an undocumented feature / bug in the PIA. I don't remember exactly how that goes. But if you copy exactly the same code as in the beginning of the Wozmon then it will be properly initialized. The trick seems to work only if this exact sequence comes after the RESET (which the PIA sees via its !RES pin) before any other thing is done to the PIA."
I foresee a couple things if we can easily reconstruct an image for the 2nd region of the ROM. first, a modified image which still uses wozmon on reset, but replaces the assembler with a dissassembler or some other tool, and/or otherwise reallocaes space used for things like CFFA1. Alternately depending on how the ROM is read, an entire 16K of other data (Or 2 additional 8K banks changeable by the Applesoft jumper). If reset is issued on the normal firmware, and then the bank switched, could you not execute machine code on the EPROMs other region then? It's a dirty trick, but I have to ask :) Cleaner of course would be to find the code Uncle Bernie referenced and prepend it to whatever program you want the EPROM to have available, and set the start point in the ROM, as then, the reset button might actually work.
Reviewing this I found a very relevant email from Claudio (P-LAB) regarding the memory mapping here.
Adding another switch would basically then render 4x 8K Banks, selectable by 2 jumpers (I would probably breadboard in a 2 position DIP switch if I found a suitable one).
I'm able now to see the structure of the ROM as described above pretty well. So now a matter of figuring out what if anything I want to or can fit in that space in a couple of extra banks. A disassembler would be awesome.
regarding the initialization of the PIA, Woz monitor relies on the fact that after a RESET the bit 2 of both control registers (CRA and CRB) are automatically set to zero, so a write to $D012 results in setting the "data direction register" instead of the "peripheral interface register" (character output). Found that at page 46 of Motorola MC6820 data sheet.
This is what's in Woz mon:
STY $D012 ; this sets the DDRA (it doesn't print the character $7f)
STA $D013 ; sets control register bit 2 to "1" so that all the writes to $D012 will result in character output
Nice, thank you for that info! As I had mentioned before and briefly discussed with Claudio, it would be neat to have the reset button auto-launch the SD OS when a certain switch/jumper is set. But, there was little/no extra room to work with in the ROM as is aside from adjusting the start point.
Here then is my thought; Krusader can be run from SD card. It would seem to me in concept for an additional ROM bank, if we reclaim the space of Krusader, we could set the start address there instead of wozmon, and have a very small program that performs the above function (beginning string of wozmon to init PIA) and then jumps to 8000R? I.e. set 4 in this theoretical example
set 1): AppleSoft Basic (E000-FEFF) + WOZ Monitor (FF00-FFF)
set 2): Integer Basic (E000-EFFF) + Krusader (F000-FEFF) + Woz Monitor (FF00-FFFF)
set 3): ?? (Disassembler?) (E000-FEFF) + WOZ Monitor (FF00-FFF)
set 4): Integer Basic (E000-EFFF) + SD Auto start (F000-FEFF) + Woz Monitor (FF00-FFFF)
Thanks again for this info; I pulled out my Apple 1 manual (reproduction, from https://www.apple-1-replica.com/) and looked at the monitor listing.
I carefully studied (as carefully as I can with a very basic understanding of machine code) the wozmon itself, and opted to try this modification in an extra bank:
At FF29, I replaced AD 11 DO with a jump to $8000 (4C 00 80)
This does mean this bank doesn't have a normal wozmon available, but the other ones all do. So, I'm pretty happy with the results at the moment. This causes the replica1 to launch the SD OS upon pressing the reset key. Because of the way I implemented the JMP where it is, if the machine is reset in the normal wozmon, and the switch is flipped after that init, the JMP is caught immediately and the Replica-1 goes immediately into SD OS. Also, CALL -151 will launch SD OS from BASIC when the switch is flipped to the modified ROM.
I am sure I will continue to mess with this, but as it appears krusader should have a disassembler, perhaps something like the cassette testing utility would be nice in the extra space of theoretical "set 3" of my last post.
I have published a video demonstrating use of the Briel Replica 1 Plus with SD OS from P-LAB, and my auto-boot reset modification to Wozmon. Comments welcomed!
I didn't see you explicitly mention this, but if you're going to live switch the ROM contents you must do this at a point where both banks have the exact same code. Otherwise the CPU will crash. I think you did mention that you picked a point where the code is looping until a key is pressed. That is a good place to do this. Or just create your own loop and have that tiny bit of code reside in both banks at the same location. It would be best de-bounce the switch so you just get a single, clean change of the address line.
Yes, I did pick a place where it appeared to be looping, waiting for the 1st keypress after the initial backslash is output.
Live swapping it while in wozmon to the hacked wozmon causes it to just catch the JMP, and start SD OS. No crash. Changing back to the normal wozmon at any time has never seemed to cause issue either.
Can you elaborate on debouncing the switch? Do you mean like using a pullup resistor so the switch to low is cleaner?
No, debouncing refers to eliminating the switch "bounce" that occurs when a mechanical switch is toggled. This can cause multiple switches between the two states within a very short time. In your case, this could cause the ROM image to swap back and forth and if the code is not identical during this time you could get a crash. There are various ways to eliminate switch bounce: dedicated circuits, RC network plus schmitt trigger, etc.
Perfect, appreciate the info, thank you.
Also, I thought your name looked familiar, I'm working on a II+ today, just put in the RomX :)