GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 Aren't there other free memory areas, like 0400h or something? Why waste RAM sharing the same range with the POKEY chip? That is what I asked Curt.. You have the HSC ROM occupying 4K at 0x3000 and its RAM occupying 2K at 0x1000. The CC2 control registers map themselves 0x0600 to 0x06FF. The XBOARD control register maps to 0x0470 with a POKEY at 0x0450 and/or 0x0460. Plus you have to contend with partial address decoding generated by MARIA . Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 If one were using the POKEY only for sound and were putting it on the same cartridge as the ROM, one could probably put the POKEY at address 0xE000. You'd need a bit more address decoding logic because the bank switch register is at $8xxx. Quote Link to comment Share on other sites More sharing options...
opcode Posted May 13, 2010 Share Posted May 13, 2010 (edited) Aren't there other free memory areas, like 0400h or something? Why waste RAM sharing the same range with the POKEY chip? That is what I asked Curt.. You have the HSC ROM occupying 4K at 0x3000 and its RAM occupying 2K at 0x1000. The CC2 control registers map themselves 0x0600 to 0x06FF. The XBOARD control register maps to 0x0470 with a POKEY at 0x0450 and/or 0x0460. Plus you have to contend with partial address decoding generated by MARIA . Still lots of free addresses in the 400h-5FFh range... Edited May 13, 2010 by opcode Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 Still lots of free addresses in the 400h-5FFh range... Not quite. You have 128 bytes of RIOT RAM at 0x480 and due to partial address decoding it can also be accessed at 0x580 too. Quote Link to comment Share on other sites More sharing options...
opcode Posted May 13, 2010 Share Posted May 13, 2010 Still lots of free addresses in the 400h-5FFh range... Not quite. You have 128 bytes of RIOT RAM at 0x480 and due to partial address decoding it can also be accessed at 0x580 too. We just need 16 bytes for the Pokey, and perhaps an extra byte for control. As I said, Curt should include a Pokey and RAM enable control with the module, so those features would come disabled and the software would be responsible for enabling them. The other thing is that RAM chips with 16KB aren't easy to find those, so Curt is probably going to use a 32KB chip. If so, why not make all of that available thru bankswitching? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 We just need 16 bytes for the Pokey, and perhaps an extra byte for control.As I said, Curt should include a Pokey and RAM enable control with the module, so those features would come disabled and the software would be responsible for enabling them. I wasn't disputing that it couldn't be done. I was just pointing out that the partial address decoding by MARIA gets in the way when you want to put peripherals below 0x1000. Quote Link to comment Share on other sites More sharing options...
Classic Pac Posted May 13, 2010 Share Posted May 13, 2010 I for one would love to see this happen Quote Link to comment Share on other sites More sharing options...
Curt Vendel Posted May 13, 2010 Author Share Posted May 13, 2010 Uggghhhh... See this is what's been delaying this for months and months over is trying to decide how best to map everything so that it works best for all... Groovey, Pacmanplus, Opcode, and others... Lets make a poll or something and decide where you want the Pokey and the RAM to reside, the HSC is already set in stone and that's not changing. Also Mark sent me a PM saying he'd like to see a header for the cartridge pinouts in the prototyping area on the board. I see no problem with that.... The prototyping area will have some socket footprints, either 2 DB9 or 1 DB15 connector and a footprint for an SIO connector... there is no reason a header footprint for the cartridge port can't be added... I'll tell you one thing, no matter what -- I'm going to have to look into doing an aluminum shield onto the module, this is a hell of a lot going on outside of the cartidge port and the RF is going to be impossible to see through with this much external bus interfacing going on. Curt Still lots of free addresses in the 400h-5FFh range... Not quite. You have 128 bytes of RIOT RAM at 0x480 and due to partial address decoding it can also be accessed at 0x580 too. We just need 16 bytes for the Pokey, and perhaps an extra byte for control. As I said, Curt should include a Pokey and RAM enable control with the module, so those features would come disabled and the software would be responsible for enabling them. The other thing is that RAM chips with 16KB aren't easy to find those, so Curt is probably going to use a 32KB chip. If so, why not make all of that available thru bankswitching? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 Whatever Curt comes up with I'll modify the ProSystem emulator so that developers can get started. The A78 header format will also need modifying so homebrew games can declare themselves as expansion module aware. Quote Link to comment Share on other sites More sharing options...
Curt Vendel Posted May 13, 2010 Author Share Posted May 13, 2010 Guys, Can we hash this mapping out in the next 3-4 days and finalize this, I am laying out the PCB mechanicals and I will start to implement the HSC portion of things, then Pokey and memory and finalize the prototyping area... I'd really like to get this all set in stone and run off a few sample test boards to get out the s/w guys in the next couple of weeks so we can all make sure it works out best and start to get some dates going for release... If anything I'd also like to try to have at least a preliminary demo unit running for CGE as well. Curt Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 Also Mark sent me a PM saying he'd like to see a header for the cartridge pinouts in the prototyping area on the board. I see no problem with that.... I'd prefer a 2x16 IDC header at .1" pitch. Preferably a right angled one built in already . The cart connectors are hard to come by, expensive and never in stock so one of those wouldn't be my first choice. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 How about some '245 bus transceivers before the header to increase the fan out? Even better if they were the LVX3245 ones that dropped the rail to 3.3v too. Quote Link to comment Share on other sites More sharing options...
opcode Posted May 13, 2010 Share Posted May 13, 2010 (edited) Ok, first the important stuff... I think Pokey should be mapped outside the 4000h-FFFFh range. I can think of somewhere in the 400h-5FFh range, but any other addresses would be fine. I believe the extra Pokey lines should be made available somehow, like the SIO, keyboard and pots. In fact that would allow us to have a keyboard expansion in the future, just like GCC had planned. The pot lines would be used for a better trackball, also just like GCC had planned (and God knows I will need one). And here is a crazy idea: Curt, I suspect you are going to use a 32KB SRAM, right? So how about using all of it? For example, you create two pages, 4000h-5FFFh and 6000h-7FFFh. Then you make it so that we can map any 8KB RAM segment to any page, however you create two sets of registers, one for the CPU and another for MARIA. Using the HALT line you can tell if MARIA or CPU are accessing the RAM, so you can switch banks based on that. This way we can have up to 2 framebuffers for 320B or 160B, or up to 4 framebuffers for 320A or 160A. Since CPU and Maria can access banks independently, we can have Maria reading from a bank while the CPU is writing to another bank mapped to the same page. How about that? Crazy but I think it would work... [EDIT] Oh, and don't forget to add some RAM and Pokey enable registers, so the user can play regular games without removing the module.... Eduardo Edited May 13, 2010 by opcode Quote Link to comment Share on other sites More sharing options...
opcode Posted May 13, 2010 Share Posted May 13, 2010 How about some '245 bus transceivers before the header to increase the fan out? That would be a good idea. In fact, Curt, how are we going to access all of that? Do you plan to have a case with holes for all those connectors? BTW, please do not forget about the case... Quote Link to comment Share on other sites More sharing options...
Eckhard Stolberg Posted May 13, 2010 Share Posted May 13, 2010 Not quite. You have 128 bytes of RIOT RAM at 0x480 and due to partial address decoding it can also be accessed at 0x580 too. Are you sure about that? IIRC from my experiments with the cartridge reader, only the TIA and MARIA get shadowed a couple of times below $400, but the RIOT is only accessible at $280 for the ports/timers and at $480 for the RAM. Everything else was available for the cartridge. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 Are you sure about that? IIRC from my experiments with the cartridge reader, only the TIA and MARIA get shadowed a couple of times below $400, but the RIOT is only accessible at $280 for the ports/timers and at $480 for the RAM. Everything else was available for the cartridge. The MARIA document from GCC shows address line A8 as "don't care" when decoding RIOT RAM. I'll experiment later to check. Quote Link to comment Share on other sites More sharing options...
Curt Vendel Posted May 13, 2010 Author Share Posted May 13, 2010 I didn't want to go crazy on the plastics, I could make some knockouts so people could mod the sides of the cases to access the ports they choose... To keep the costs down, I'll put in footprints for the xceivers and let people install themselves. I want to try and make this so that its a balance for out of the box users and modifiers to offer future upgrades to it and allow the modules to have some legs to them... GCC original proposed the CPU to go out of the cart port, but was shot down because of RF concerns, thats why they went through the front controller port. Curt How about some '245 bus transceivers before the header to increase the fan out? That would be a good idea. In fact, Curt, how are we going to access all of that? Do you plan to have a case with holes for all those connectors? BTW, please do not forget about the case... Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 The MARIA document from GCC shows address line A8 as "don't care" when decoding RIOT RAM. I'll experiment later to check. Just wrote a little piece of code that fills $480 to $4FF with a known pattern in a loop and then reads it back and compares against what is expected at $580 to $5FF in a loop. The pattern written is read back OK. As a validity test of the code I also wrote a different value into arbitrary address $492 after the pattern write and the read and compare loop then fails. The GCC MARIA document checks out OK. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 To keep the costs down, I'll put in footprints for the xceivers and let people install themselves. I want to try and make this so that its a balance for out of the box users and modifiers to offer future upgrades to it and allow the modules to have some legs to them... Personally, I think everything up to and including the 2x16 row .1" pitch IDC (or whatever the internal connector turns out to be) should be built in as standard. Not everybody is happy using a soldering iron but I suspect they'd be happy to plug in a new board if it was easy to do so. Quote Link to comment Share on other sites More sharing options...
Shawn Posted May 13, 2010 Share Posted May 13, 2010 Forgive my ignorance but I thought this was gonna be an internal mod that went inside the 7800? From the last couple of pages of this thread I assume I'm wrong and this is an external add-on? Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 For example, you create two pages, 4000h-5FFFh and 6000h-7FFFh. Then you make it so that we can map any 8KB RAM segment to any page, however you create two sets of registers, one for the CPU and another for MARIA. Using the HALT line you can tell if MARIA or CPU are accessing the RAM, so you can switch banks based on that. This way we can have up to 2 framebuffers for 320B or 160B, or up to 4 framebuffers for 320A or 160A. I like this idea too. Think bigger! I'd like to see 128K of RAM accessed this way. With G2F and the 169 colour mode available graphics could be compressed in ROM and expanded into the RAM. Audio/music samples could be decompressed and stored, game worlds could be bigger and so on. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted May 13, 2010 Share Posted May 13, 2010 Forgive my ignorance but I thought this was gonna be an internal mod that went inside the 7800? From the last couple of pages of this thread I assume I'm wrong and this is an external add-on? Its an external add on. It sits in the normal cart slot and offers a pass through for standard carts as well as extra functionality. Quote Link to comment Share on other sites More sharing options...
Bakasama Posted May 13, 2010 Share Posted May 13, 2010 I've seen concept art for the casing of the module. It kind of looks like 2600 jr. with no switches sitting on a 7800. Quote Link to comment Share on other sites More sharing options...
gambler172 Posted May 13, 2010 Share Posted May 13, 2010 Hi Curt Whenever you need a tester,let me know.I would be happy..... greetings Walter Quote Link to comment Share on other sites More sharing options...
opcode Posted May 13, 2010 Share Posted May 13, 2010 For example, you create two pages, 4000h-5FFFh and 6000h-7FFFh. Then you make it so that we can map any 8KB RAM segment to any page, however you create two sets of registers, one for the CPU and another for MARIA. Using the HALT line you can tell if MARIA or CPU are accessing the RAM, so you can switch banks based on that. This way we can have up to 2 framebuffers for 320B or 160B, or up to 4 framebuffers for 320A or 160A. I like this idea too. Think bigger! I'd like to see 128K of RAM accessed this way. With G2F and the 169 colour mode available graphics could be compressed in ROM and expanded into the RAM. Audio/music samples could be decompressed and stored, game worlds could be bigger and so on. Sounds good. Hey Curt, two votes here, how about that? About the case, how about having the holes already on it, and leaving the connectors for the user? Wasn't you planning to support the 7800 keyboard with the module, or was it another thread, I don't even remember... Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.