|
Post by gtoal on Nov 3, 2017 19:58:37 GMT -5
I don't think it's possible because of the way the address decoding logic is set up, it's not a dedicated chip it's some TTL NAND and OR gates if you check the schematics for top 4 address lines (A12-A15) console5.com/techwiki/images/c/cb/Vectrex---Logic-Board.pngsomeone correct me if I am wrong, please. Aha! Thanks for that diagram - it shows the edge connector pinout much more clearly than the doc I had found. Looks like there is no problem with accessing all the address pins from the CPU including the vital A15. I think this is doable! (Maybe not by me and certainly not quickly enough for a Christmas release of Tailgunner as I had hoped, but definitely possible on a longer timescale) I have some old hardware I might be able to use in this project - I have a PLA I built back when I worked at Acorn that decoded the address space of a 6809 second processor that I built, which I might be able to reuse if it decodes the right areas - it was a ram controller for a 64K dynamic ram with a boot rom overlay...; and I have an FPGA kit I bought on Kickstarter some years ago that I haven't got around to using yet! - maybe now is the time :-) Actually I also have some 74ls139 chips and I think that just using sel0 and sel1 with A15 and A14 ought to be all that is needed to create an enable for any access between 8000 and bFFF, no? i.e. divide the address space into 4 - the outputs will correspond to 0000-3FFF, 4000-7FFF, 8000-BFFF, and C000-FFFF - the last one negated can be used for 0000-BFFF? Ooh! I just remembered! I have a bunch of 32K static ram chips left over from a BBC Micro project! Breadboard here I come :-)
|
|
|
Post by gtoal on Nov 3, 2017 22:25:12 GMT -5
Hey - does anyone sell a bare edge connector that breaks out the signals from the Vectrex that I could use for breadboarding experiments? (before I find the one ROM cart I have somewhere and hack it up with a dremel...)
|
|
|
Post by gauze on Nov 4, 2017 0:04:17 GMT -5
Hey - does anyone sell a bare edge connector that breaks out the signals from the Vectrex that I could use for breadboarding experiments? (before I find the one ROM cart I have somewhere and hack it up with a dremel...) I have some spare cart PCBs that should be fine for this, if you are in the US PM me your address I'll just send you one.
|
|
|
Post by gtoal on Nov 4, 2017 0:13:24 GMT -5
done, thanks :-)
|
|
|
Post by gtoal on Nov 7, 2017 14:52:26 GMT -5
Is it possible that the reason the 8000-BFFF space has not been used in other carts is because the Exec rom is duplicated in those locations? (ie if it doesn't fully decode it's address?) I don't *think* that is the case from the circuit diagram but I'm still struggling to work out why no-one has built 48K roms. I can't help but think that if it were possible someone would have done so by now.
Aha! I don't need to build hardware to test this - I can write a quick hex monitor/memory browser and actually look at what responds in that address range and see if it matches what's at some other addresses... (As long as it isn't ghosting some hardware register..!) Undecoded space could show up as either all 00 or all FF or completely random depending on the hardware :-)
|
|
|
Post by gtoal on Nov 7, 2017 20:24:55 GMT -5
Aha! I don't need to build hardware to test this - I can write a quick hex monitor/memory browser and actually look at what responds in that address range and see if it matches what's at some other addresses... (As long as it isn't ghosting some hardware register..!) Undecoded space could show up as either all 00 or all FF or completely random depending on the hardware :-) OK, I hacked up a short program to display the contents of the memory in hex (and the active line in ascii, but there was only room for one line in ascii so it's not my usual style of hex+ascii dump) Navigate with the buttons - 1 and 2 move by 0x10 bytes and 3 and 4 jump by 0x800 bytes, so you can navigate the whole memory space relatively quickly. Could folks with the hardware and a ram cartridge take a few minutes some time in the next day or two, to try this program please? (Also it's worth comparing results from more than one machine, especially if there's a chance that the results are affected by whichever ram cartridge you use?) www.gtoal.com/vectrex/ram/ram.binand let me know what you see in the 8000-BFFF range. (Source is in www.gtoal.com/vectrex/ram/ram.c (.html) - it was a quick hack, and it will flicker a lot, but it should work enough to find the info I need) Do you see a single byte repeated throughout, or some pattern repeating on some size of cycle, or does it look familiar and like something at some other memory location? (fyi the emulator shows FF throughout) thanks! Graham
|
|
|
Post by gtoal on Nov 8, 2017 23:45:30 GMT -5
btw I've ordered some used 27512's and an EPROM burner + eraser for this 48K eprom experiment! And thanks to Gauze for the info about them, I've put in a Christmas present request to my wife for one of these next generation cheap logic analysers that I wasn't previously aware of :-) (Though I have to say I'm impressed that you can get an old 80's HP logic analyser that still works well for under $100!)
G
|
|
|
Post by gtoal on Nov 10, 2017 1:30:14 GMT -5
While I was pondering how to build a 48K cartridge, a thought crossed my mind... The 6809 is 1MHz and modern processors are a lot faster, for example the ARM in the raspberry pi is 700MHz at least.
So if you could connect the address bus and clock to GPIO inputs, you could sample 16 GPIOs when the E clock goes high, and read the requested address, and then wait for the Q clock to assert, and put the data for that address (out of a 64Kbyte array) on 8 GPIOs configured for output. The 8 data pins should be set as inputs or tristated when Q is low or R/W' is R.
If all this can be done within 700 clock cycles then the Pi could impersonate a Rom as far as the 6809 sees it. Even with some jitter introduced by the OS, it ought to be able to work within that many cycles.
We'd need 16 pins for addresses, 8 for data, 2 for E and Q, and 1 for R/W'. With a bit of tweaking to disable the pins used by the OS for I2C etc, the Pi actually has just enough GPIO pins to pull this off with one spare.
Then when I had worked all this out, it occurred to me this is probably very similar to what the Vectrex32 card is doing? except with a PIC32 rather than an ARM SOC, and probably no interrupts enabled, and a lot fewer available clock cycles! I'm guessing the Vectrex32 generates 6809 code to draw the vectors generated by the PIC32 system?
If so, does that mean that the Vectrex32 with different software could also function just as a ram/rom cartridge?
|
|
|
Post by gauze on Nov 10, 2017 9:22:00 GMT -5
I have wondered why it doesn't have a BASIC program that can load an arbitrary ROM file so you can use it as a "flash cart" before on public forums. I don't know if there is a technical reason or if it's just that bob is keeping his platform "just BASIC" for philosophical reasons.
|
|
|
Post by Mayhem on Nov 10, 2017 12:40:45 GMT -5
If you are going to build a 48k cart, might as well see if you can fill 64k, banks are 32k each.
|
|
|
Post by gtoal on Nov 10, 2017 14:33:45 GMT -5
If you are going to build a 48k cart, might as well see if you can fill 64k, banks are 32k each. No, the point of this is to avoid bank switching - to use 64K you would be back in the land of bank switching again. Coding would be *much* easier with a flat linear 48K address space available. What I'm proposing is basically just adding one more gate to a standard rom cartridge, to decode A15 *and* A14 rather than just A15. It looks like it should be trivial and something that could have been done years ago - probably even what was planned by the designers given that they placed the BIOS and devices at the high end of memory, leaving an undecoded gap immediately following the 0000-7FFF rom space. I mentioned this on Facebook and folks there were also recommending using bank switching, but to me that should only be done *after* using all of the 48K that appears to be trivially available. There's a small overhead from the actual bankswitch instructions, and a slightly larger overhead (in C at least) from the thunk that is generated to call procedures in another bank, but my main objection is the amount of organisation that has to go into your code to ensure that everything that executes within one bank doesn't interact in any way with code/rom data that is in the bank that is currently rolled out. Code is seldom so cleanly partitioned that you can find one single function to separate out like that. In the case of tailgunner what I am working on is a large set of pre-rendered vectors for the 3D views of the ships, and unless they were all to fit inside one bank along with the code to draw them, you would be bank-switching continuously. I mailed a couple of other folks who don't hang out here, who have built cartridges, to ask them if what I'm suggesting makes sense. No-one has said it won't work, so I'm definitely going to go ahead and try it, as a minor mod to a standard ROM cartridge. However if I were designing a new cartridge, it would probably be along these lines: use a 64K x 8 static ram and a wifi-connected micro to program it, and a couple of digital switches or tristate buffers so that the ram could be disconnected from the Vectrex bus while being controlled by the micro. The micro would have some flash memory built in and that could retain the uploaded data - hence why we could get away with using 64K of RAM rather than EEPROM. This is sort of similar to Vectrex32's dual-ported RAM (I read his docs last night - it's 2K of true dual-ported RAM, not the hack I suggested in that post above) but it wouldn't be truly dual-ported - it would just be switched from one bus to the other dynamically. By the way, because he only has a 2K code buffer, that's why he can't use his hardware as a standard ROM cartridge as well. For controllers, there are a bunch of things available from arduino-like PICs to ESP8266's and STM32's. Chips that don't offer 28 GPIO's would require some extra hardware to access the RAM (eg shift registers and an address counter for bit-serial access) but that's all doable - it's how things like serial EEPROMs work in the PIC world. I'm afraid I've digressed somewhat from the ostensible subject of coding Tailgunner in C. I suppose as the person who started the thread I'm allowed to, but apologies to anyone who is losing interest. Maybe I should start another thread about cartridge design and return this one to its original purpose... G
|
|
|
Post by VectorX on Nov 10, 2017 14:47:16 GMT -5
^Topic can drift a bit, as it sometimes does. It's up to you though.
|
|
|
Post by gtoal on Nov 12, 2017 1:51:01 GMT -5
While I was pondering how to build a 48K cartridge, a thought crossed my mind... The 6809 is 1MHz and modern processors are a lot faster, for example the ARM in the raspberry pi is 700MHz at least. So if you could connect the address bus and clock to GPIO inputs, you could sample 16 GPIOs when the E clock goes high, and read the requested address, and then wait for the Q clock to assert, and put the data for that address (out of a 64Kbyte array) on 8 GPIOs configured for output. The 8 data pins should be set as inputs or tristated when Q is low or R/W' is R. If all this can be done within 700 clock cycles then the Pi could impersonate a Rom as far as the 6809 sees it. Even with some jitter introduced by the OS, it ought to be able to work within that many cycles. We'd need 16 pins for addresses, 8 for data, 2 for E and Q, and 1 for R/W'. With a bit of tweaking to disable the pins used by the OS for I2C etc, the Pi actually has just enough GPIO pins to pull this off with one spare. Frank Buss just pointed out this link to me: spritesmods.com/?art=veccart&page=2It's exactly what I was thinking about above (except possibly without the 48K address space) - now I wish I hadn't spent the week researching components to design one of these! :-) G
|
|
|
Post by Malban on Nov 12, 2017 4:53:05 GMT -5
Hi,
I just would like to say some few words on the current topic. If you want to design new cartridges - new/old ways of accessing ROM from the Vectrex side, everything is fine with me.
If you are doing the cartridge design only because some generated vectorlists do not fit into the current space of 32k than my first reaction is:
„Mit Kanonen auf Spatzen schießen“ - German
Translation as provided by the internet:
„ to take a sledgehammer to crack a nut [fig.] “
a) My first notion in this case would be - try to shorten the lists so they fit. 32K for vector lists is HUGE, especially if I have to keep in mind there are only 2 different animated ones: a) the plaque b) the enemies
Perhaps you are using to many?
b) If you really need more space (I know it has been said so several times before) there is bank switching.
Pro: It is cheap There are several AVAILABLE pcb designs that support it. It is basically one more line on the pcb, that’s all. There is no need for additional controllers or chips of any kind (perhaps a resistor).
It is easy to handle and fast. The timing costs of bankswitching (vectrex side) is virtually non existent - one cycle it is this bank, the other cycle it is that bank. Provided you have the program setup you can draw your first 10 vectors in one bank and the second half in the other - it doesn’t make much of a difference.
It is documented and working - bankswitching routines are available.
It is emulated by all emulators (might not be a big argument though).
Contra: Its not available for „C“ (yet). It is not something fancy new.
If you are looking for „easy“ routes IMHO this is the route you should take. Since you decided to do „C“ instead of „Assembler“ for Tailgunner my estimate would be you should try bankswitching. If you design a new cartridge type with a controller etc… You have to program that as well - debug it, change faulty already manufactored pcbs because one line doesn’t go where it is supposed to go etc etc etc…
To me this seems like a dramatic overhead. It might even be easier to program Tailgunner in assembler instead :-).
Two other „Words“
Bankswitching This is the code to switch to bank with „dondzila“ Bankswitching:
switchToBank1: ldd #$9FFF ; Prepare DDR Registers % 1001 1111 1111 1111 std >VIA_DDR_b ; all ORB/ORA to output except ORB 5, PB6 goes LOW jmp main ; Basically jump to main loop
To switch to bank 0 change the #$9fff to #$dfff. After the „std >VIA_DDR_b“ you are in the other bank. It is essential that the code "on the other side" is known.
Usually you place your bankswitch routines at exactly the same memory location and handle „jumping“ to the right place thereafter - which is „easy“ since RAM stays the same - so you can transport your final destination via RAM or registers.
- To support bankswitching in „C“ basically one only needs above routine added to the crt0 and thus ensure that the code is always exactly at the same memory location.
- Do handling of the function you would like to call or return to on the other side.
- Generate two 32k bins and concatinate them.
- Than run the resulting 64k bin on an emulator or on a PCB that supports bankswitching.
These four steps I haven’t done for „C“ in vide. Since you do most of your programming with CMOC - that doesn’t really matter - since it is the same for both. It seems to me that doing these steps would be much easier than building new cartridge designs.
Cartridge The way you want the cartridge to access RAM/ROM via a „controlled“ CPU interface - is exactly what Thomas Sontowsky did for his VecFever. One result is, that - if configured correctly - :
a) You can useall ROM also as RAM b) he can manipulate RAM/ROM from his controller (HighScore saving comes to mind) c) he can access the Cartridge "BIOS" from „HotSpots“ within his code d) he can do bankswitching up to 4096 (is right - isn’t it?) banks e) etc etc
Regards
Malban
|
|
|
Post by Malban on Nov 12, 2017 6:22:26 GMT -5
PS
You can also generate the Bankswitching code to RAM and jump to a RAM address to do the switching. That way you can even use "self modifying" code to go easier on the target location - since you can use function variables.
I guess in your case this is even MORE easy than the above described route - since this can be done without modifying any crt0.
The only "problem" is to get the address correct from the other "bank" have to ponder over that ....
Malban
|
|