First some context, then some questions follow :) I have mentioned before, I think, that I am working on a PET core for the Mega 65. See https://github.com/Rhialto/PET2001_MiSTer/ and https://github.com/Rhialto/PET_MEGA65 . The published version is up to a 8296-D. I am working on the SuperPET part now (none of that is visible on github yet, though). The Waterloo languages seem to work (I successfully ran a simple Pascal program). Yes, I wrote a 6702 in Verilog. I am looking at the SuperOS/9 MMU, which looks to be fairly simple. I implemented it already in VICE years ago, but now that I look at the actual schematic, it seems I have left some stuff out and it still even works. The basic description of how it works (from https://mikenaberezny.com/hardware/superpet/super-os9-mmu/ ) ===================================== Operation A stock SuperPET has a total of 96K RAM. It contains 32K from $0000-7FFF, as a CBM 8032 does, and an additional 64K of expansion RAM. The expansion RAM is divided into 16 banks of 4K each. Writing to the bank select register at $EFFC selects bank 0-15. The currently selected 4K bank is mapped into $9000-9FFF. For more information on the stock SuperPET, see André Fachat's pages. The Super-OS/9 MMU is a daughterboard that plugs into the 6809 socket on the SuperPET. It only works in 6809 mode. It expands the SuperPET expansion RAM bank select latch at $EFFC (on the combo board, 74LS273 U36). Bit 4 - Unused on Stock and MMU Bit 5 - Unused on Stock / OS9SELECT on MMU Bit 6 - Unused on Stock / FIRQDISABLE on MMU When bit 5 is high, the OS-9 memory map is activated. In this map, the 6809 sees 64K of contiguous RAM from $0000-FFFF, all physically located in the SuperPET expansion RAM. There is no access to the $EFFC latch once in the OS-9 memory map. This is where it gets interesting. To get back to the usual SuperPET memory map, the code executes the 6809's SYNC instruction. This instruction blocks until an interrupt occurs (similar to WAI on 65C02). When the 6809 is in "SYNC mode" waiting for an interrupt, two output pins on the 6809 indicate this condition: BA=1 and BS=0 (called "SYNC Acknowledge" in the datasheet). The MMU board has logic gates that detect this. It then resets the latch to return to the SuperPET memory map and generates an /FIRQ ("fast interrupt"). The /FIRQ pin is unused in the stock SuperPET. When the /FIRQ triggers, the SYNC instruction stops blocking, and the software can resume in the SuperPET map. ===================================== Now in VICE I totally do not look at these BA and BS signals. I am cheating and the emulation is directly coded in the SYNC instruction. It pretends that a FIRQ is fired immediately and it doesn't need to wait longer than that. I don't even bother to call the FIRQ vector. And it still works. Looking more closely at the schematic (https://mikenaberezny.com/wp-content/uploads/2009/11/superos9-mmu-schematic-r2.jpg) I see that when the FIRQ is fired, also the bank select register is cleared including the selected bank number (which also clears the OS9SEL bit which is in there). In VICE apparently I didn't look at this and do not reset the bank number. Fortunately it still works: OS9 always stores bank number 0 when it enables the flat address space. Now we're getting close to the first question :) BS=0 and BA=1 contribute to FIRQ. But BA by itself is also combined with the OS9SEL line before it goes into the address multiplexers. I didn't count all the negations underway, but it seems that if BA=1 then it immediately affects the MUX (selecting the default superpet addresses). Why is that there? If the route via clearing the register is too slow (there could be a cycle of delay in that path) then why is BA used by itself and not the signal where BA and BS are combined? Or is there some use to disable the mapping while "HALT ACK" (BA=1 BS=1) is active? Second: it seems like the descriptions of bit 5 and 6 have been swapped. At least in VICE they are the other way around, and also on the other schematic https://mikenaberezny.com/wp-content/uploads/2018/03/superos9-mmu-schematic-nils-eilers.pdf . This was confusing me and the first time I did them as described, i.e. wrong :) Third: I When trying to boot Super-OS/9, Super-OS/9 hangs on the text screen which tells you the version numbers and the copyright. Just before it would normally ask you the date and time. Any ideas about what could be wrong? It doesn't appear to be trying a SYNC instruction, but the IRQ line is active (low) for quite a while at this point. I can use a virtual scope at this point, but debugging at machine language level is tricky this way. I can see it appears to be execting instructions, and apparently it isn't reacting to the IRQ. In VICE I have seen that usually the IRQ is masked and it is unmasked from time to time explictly. Fourth: And why doesn't it work with the .D80 disk image in a 8250 drive? It works when I use a 8050 drive. It fails before the text screen that I just mentioned, while loading the "ROM Modules". Copy/pasted from VICE, which converted everything into upper case: LOADING 'DISK/0.OS9.MOD' MMU SOFTWARE INSTALLED AT $9600 & $0600 LOADING SUPER-OS/9 ROM MODULES... PLEASE WAIT... LOADING ABORTED DUE TO READ ERRORS WATERLOO MICROSYSTEMS SELECT : SETUP MONITOR APL BASIC EDIT FORTRAN PASCAL DEVELOPMENT VICE reports many instances of Filesystem Image DXX: Error - Track 19, Sector 35 out of bounds. Error - Cannot read T:19 S:35 from disk image. I wonder why this happens in a 8250 drive but not a 8050. -Olaf. -- ___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl> \X/ There is no AI. There is just someone else's work. --I. Rose
Archive generated by hypermail 2.4.0.
