Jump to content

retro_doog

New Members
  • Content Count

    21
  • Joined

  • Last visited

Community Reputation

16 Good

About retro_doog

  • Rank
    Space Invader

Recent Profile Visitors

1,298 profile views
  1. OK, after starting a two EEPROM version of the AnyCart with an ATtiny and scrapping it... And then completing a schematic for a mixed EEPROM(for ROM) and ATmega+SQI ROM(for GROM), all the way to floor planning, I've decided to park that implementation as well. Still too many compromises and kludges/muxes/messy stuff. So. I now have a 75% complete schematic of "Third Time's a Charm" goodness! I've decided, I don't really want to just make just another, albeit improved, version of a ROM/GROM cart. I want to make a cartridge development platform! So I've jumped straight to a 44-pin ATxmega class processor, which is only a buck more than the 32-pin ATmega I was using before, with the following benefits: 44-pins(of course ) - Turns out the TQFP44 has the same pin pitch of .8mm as the 32-pin, so other than the extra 12-pins, the soldering won't be that much of an extra challenge. I can do 1.27mm SOICs without my "Nerd Goggles" and can somewhat painfully handle .65mm TSSOPs and .5mm VSSOPs, so I'm confident these will go down relatively easily. 32-Mhz operation and all from the internal oscillator. This actually saves me a $0.50-$0.70 crystal, so the Xmega upgrade is even cheaper! Also, I hear people can run these at 48Mhz with no issues and still from the internal oscillator to boot! USB, baby! Although my initial code base won't have the hooks in and I'll be using my ICE to flash the AVR and my custom SPI programmer for the flash, eventually, I'll have boot loader code and a way to flash the cart over USB. It will probably still require preparing a binary, but still, the cart will ultimately be able to be flashed without cracking it open. I plan to put the mini USB on the side so you can never have it powered by both the console and USB at the same time. If I had the newer white cartridge shells, I could have put it in the cart slot area to the side of the card edge connector. Still, when the cart is inserted, the USB won't show. Unified SQI flash ROM Yup, a tiny 8-pin SIOC with up to 8M(Maybe more) of flash. The only downside is that I have to run the XMEGA off of 3.3V and therefore have to level shift the entire cartridge slot. But I already have that worked out as well as mixing(well, tristate bussing) the 8-bit data bus with the lower byte of the address bus, since I'll never need both at the same time(The console won't be able to write to GROM). Even at 48Mhz, with 24Mhz SPI, I'm still too slow to do straight ROM access with single bit SPI, but I figure the 32-48Mhz boost over the ATmega's 20 Mhz should make it easier to emulate the SQI bus at a rate faster then single bit automated SPI can handle. I have an idea where I preload the first 12-bits of the address whenever I go to Idle to get a head start. Then, if a ROM access comes in, I'll only have to send the last 3 nybbles of the address and fetch the data. For the second half of the read cycle, the auto-incrementing behavior of the SQI flash should make it easy to fetch the second(Even?) Byte. Depending on stuff, The ROM images may have to be "re-endianed" to line up with this, but that's just byte shuffling and can be done in a script if needed. Now, If we're sitting at Idle with our ROM bank address preloaded into the flash and a GROM access comes. I just pull the chip select high and start over with loading the GROM base address. The delay is no problem since GROM is Soooooo Slooooooooooow compared to CPU ROM. So, this one's a keeper, and the floor planning is looking good. I have all the level shifters down in the "squeezed" area of the cart where the shell Z-height restrictions are tighter, which is where they want to be anyway, right next to the card edge signals. The only task left is to hook up the busses to the AVR, which is an iterative process that I'm doing in conjunction with layout to make routing easier(i.e. I can reorder signals to make them mostly run parallel to the AVR ports). I probably won't have a lot of time for layout in the next week, but I wanted to make sure the schematic was done so I didn't forget any of the fine details. Still, I have a bunch of PCB stuff backed up, so I'm pretty motivated to get this done so I can send everything out for fab at once. I'll keep everyone posted.
  2. I'm not too familiar with the GRAM Kracker myself, but that is a good question.
  3. Sure, that's my point. A GROM device is a synchronous device, albeit in it's own clock domain. My design will attempt to reproduce the synchronous behavior of an actual GROM. I now have come to realize that you have chosen to implement your design in an asynchronous manner, which was not immediately obvious to me. We're both engineers here, and we know there is more than one way to implement a design. My implementation will be closer to emulation, yours seems to be closer to simulation. Both methods work as your design has proven. Yes, I now realize that GROM operations are a series of individual atomic CPU access cycles and not a monolithic operation like I had assumed. My assumptions made sense to me based on how other sequentially accessed ROMs operate, including TI's own TMS6100 Speech ROMs which I had just completed an AVR based ROMulator for. Since the GROM was not openly specified by TI and I have yet to find an actual TI published timing diagram, I'm left to deal with interpretations based on the work of others like yourself. Haha! I like you. Of course it's not laid out, just schematic and floor-planned. However, I can go all the way to fab and assembly before I need to know exact details. I just run every control signal to the AVR, and mux the two nybbles of the data bus to both the AVR and to the SQI flash, and the rest is just "typing"(my former manager's word for software ) Your advice is much welcomed, and your knowledge of the system is extremely helpful! I'm choosing a different path by implementing synchronous near-emulation, but that doesn't mean I don't have respect for your design or the work that went into it. My background is in synchronous ASIC I/O bus and host controller designs including multi-clock domain situations(33/66Mhz PCI to 50/100MHz FireWire), so I'm naturally gravitating towards the design style that is in my wheelhouse. Other than quicker response time and probably not responding to address reads, I would like my GROMulator to behave both internally and externally most like an original GROM. Again, thanks for all the useful input
  4. I clearly need to read the GROM spec more closely. I thought the GROM clock was what latched in the address bytes and synchronized the control signals. Also, I thought the auto incrementing sequential data cycles were just a series of GROM clocks with the next sequential byte's data at each GROM clock edge. If this is not the case, then GROM is much slower than I thought so I guess I'll have no problems. It will be more clear when I look at the appropriate flow charts or simply take some logic analyzer dumps. I do realize the GROM Clock is in a different clock domain, but I assumed these were still synchronous devices. The actual GROM chips surely require this clock and I still plan to synchronize my GROMulator to that same clock. I'm going to run my software state machine for GROM emulation off the GROM clock either by sampling the clock, or, more likely, routing it to a pin change interrupt and emulating a clocked state machine from that mechanism. Doing everything that is in the GROM flow chart completely asynchronously could expose some of those latent bus contention situations I talked about earlier. Also, I would be inclined to believe that the internal address counter in an actual GROM actually counts on GROM clock edges. So, the big challenge will be straight non-GROM ROM access. My understanding is that I will only have four 333nS CPU clocks total to decode the address, fetch data from the SQI ROM, and drive present it on the data bus. If so, timing will be pretty tight and I may just have to build the thing and see how good I can get the software and then decide how much over clocking if any I need to guarantee timing. Because of that, I may also put a "chicken ROM" down so I can at least have 512K-1M of parallel ROM if I can't get shared serial ROM to meet timing. I have a sort of AVR dev board on hand that is not an arduino, so maybe I should whip up some test code to see how fast I can emulate the SQI bus. Also, is anyone clamoring for 8K of RAM in the cartridge space? Due to the bank/title select's use of lower address lines, I thought of having only the upper 4K as an SRAM option. Thats still, 16x what the built in console has, and many/most are utilizing various schemes to get the proper 32K expansion either with PEB emulation like the CF7+, putting the 32K in the console, or having actual PEBs. The SRAM I'm putting on the cart will be more like the battery backed Mini-Memory SRAM, although it can be used for volatile data if a title want that too. However, it will be nonvolatile and NOT need a battery… ever! It's a semi-new technology that has a flash backed SRAM implemented at the bit level. What I may do with the 8K chip is split it into 2 banks so that if you use the mini-memory built in cart, and later want to use a non-minimemory title that just wants volatile RAM, it won't overwrite the minimum 4K partition. The descriptor will have a bit that chooses which bank of 4K SRAM is active, if any, for a title.
  5. Ah, very helpful, mizapf! The link to that book I had on my iPad, didn't have Appendix G included! So I see now that there is a mechanism to switch the 2.2K resistors from pull-ups to pull downs on the 8-bit data bus to the GROMs. This also seems to suggest that while the GROMs are PMOS, the chips that interface to it are NMOS and that all MOS devices are open-drain. Looking at GREADY(GRY in the sch) is interesting. It has a pull-up! So, it looks like there is a very good chance that the PMOS GROM has an NMOS GREADY signal! So the Not-Ready state cold easily be asserted by all chips and you're not ready until every last ROM releases the not ready state. So… It could be fun to make a multi-cart that also has the console ROMs onboard. You would have to pull the internal console ROMs for it to work, but you could possibly speed up the whole system that way! Does the later v2.2 refer to Console ROM or GROM0? This could be a way to help out those v2.2 folks who can't run ROM only carts I may make this an option for the multi-cart. Custom non-extended basic, anyone? Why?…. Why not! Thanks for pointing me to this resource The other books will come in handy too. More night time reading for my iPad!
  6. Hi Tursi, Sorry up front , I don't know how to properly reference split quotes, so I'll just indent and color any quotes below: So it looks like I won't have to worry about processing time with GROM in general, so that's good. The hold (or rather, READY) signal is an important part of being a GROM. I wouldn't recommend leaving it out on purpose even if you don't think you want it today. Sorry, I may not have been clear. I was referring to not having a way to hold off straight ROM accesses, which I am also trying to implement in a single flash resource. GROM operations take 14-30 GROM clocks. You aren't anywhere near being slow. You are also not required to use the GROM clock, nothing else in the system relies on it. I take it into my AVR but I don't use it. Wait, GROMs are more or less synchronous. How can you know when to sample all of the control signals, particularly since access can have multiple phases (Load Addr H, load Addr L, etc.) Most importantly sequential data accesses surely need to be synchronized to the GROM CLK do they not? Reading back gives you the correct address, although no chip responds to that range). The data bus is likewise not strongly driven, but I need to double-check the details. Reportedly there is a pull-up on the bus in one direction and a pull-down in the other, so you need to drive it correctly. (TTL can dominate that system, which is how the old GROM devices would override it.) So during an address read, every GROM chip drives the bus at the same time? Normally that would be a nightmare if one of the GROMs had a corrupt address load, but, being PMOS, I guess they can get away with that since there is no possibility of contention. However, I will capitalize on this behavior and not have my GROMulator respond to address reads at all, since the console ROMs will cover reporting the loaded address for me Hmmm, this does make me realize I may want to put a stage of PMOS open drain buffering on the data bus to prevent possible contention. Mizapf is right on the operation of READY. GROMs are /always/ "not ready", except when they have completed an operation. That makes perfect sense to me, however, I may have been confused by this statement then: If you're fast, the other GROMs still hold the bus the normal duration anyway, I took this to mean that for every GROM cycle, the CPU doesn't "see" the GREADY until every GROM chip says they are ready. In other words, for a given access I thought you were saying that even if I complete my access super fast and assert my READY, the console GROMs, for instance would block it until they also say "ready". Or were you simply stating that my accesses will be fast, but whenever access occurs to a different GROM those particular slower accesses will bring the average access time down. However, knowing that the devices are PMOS and that the GREADY is active High, I would think that no GROM can override my GREADY High since no PMOS device can drive low. Reportedly there is a pull-up on the bus in one direction and a pull-down in the other I'm probably misinterpreting this as well. I could see if NMOS devices are mixed with PMOS devices, that the NMOS drivers would have weak pull-ups and the PMOS drivers would have weak pull-downs, and any TTL(Or CMOS even if TI used any such devices in the console) can easily overdrive am otherwise non driven bus. However, since the data bus is bi-directional by design, that would suggest that an un driven bus is not actually tri-state, but floats somewhere in the middle due to the resistor divider created by the NMOS pull-ups and PMOS pull-downs. Looks like I'll need to put an oscilloscope on the bus as well as the logic analyzer. I'm working with a PMOS device emulation in my speech synth ROM project, and my goal is to completely understand the circuit, otherwise there is a real possibility that my replacement device, and my multi-cart for that matter, might have slivers of time where there is real bus contention that, over time, can degrade the components and cause long term damage or failure to the system. I should probably put a scope on the actual ROMS used in the carts as well to see if they are PMOS or NMOS or if they have a TTL output stage(unlikely). There's a very good chance that the parallel ROMs are NMOS as that was a popular technology due to having higher bit density. Actually, it occurs to me that the reason that the GROMs are characterized as weak drivers even by TI's admission, is because they are using under sized PMOS transistors. In general a properly balanced CMOS gate(balanced for speed or drive which is related to speed), the PMOS high side FET is physically larger to achieve the same timing and drive as the NMOS low side FET. I forget how much larger, but close to 2X IIRC. I should pull out my old VLSI design book and look it up. I'd been writing RTL for so long, sometimes I forget about the transistors that are begotten(begat?) from the code Anyway, pull-ups and pull-downs(and PMOS and NMOS) are pretty easy to spot with a scope. If the rising edge is fast and the falling edge is slow, you have PMOS with a pulldown and vice-versa for NMOS. The other question for technology this old is where the resistors are. I would have no problem believing that the PMOS and NMOS(if any) chips simply have open drain drivers and that the "pull-me" resistors as I generically call them, are passives on the board or a "bus parking" terminator of some kind. It may do me well to hunt down the console schematic if it's out there and see exactly what I'm dealing with before I start "playing on the bus" Again, thanks for the help and clarifications! If I learn anything new and interesting, I'll be sure to share Like This Quote MultiQuote
  7. Oh wait. You mean the Console GROMs will hold the GREADY inactive(LOW) until they decide the address is not in their space? So all of the GREADY are wired AND together and are not Totem-Pole or Push-Pull? I thought GROMs were PMOS. Hmmm I better do some more research on that aspect of the GROM electrical specs. Still, I definitely don't want to be the slowest GROM in the box. Note that your GROMulator has parallel access to the internal flash in the AVR you chose. I'm using an external SQI flash. If I just used 1-bit SPI, the initial flash access would be 8+24+8 clocks at 4Mhz(the max SPI can run when the SysClk is 8Mhz) and would take 10uS plus some overhead to present the parallel data on the bus. Subsequent Sequential Data Cycles would be right at 2uS + Overhead and would be just about the exact rate for the SPI clock. However, if we creep just over the line, we have to wait over 2uS until the next GROM CLK to get the data and would effectively be 2x slower. But, I'm confident that whatever I lose in Nybble-Banging SQI, I'll get back in the 4x data throughput so I'll definitely be to deliver sequential data at the GROM CLK rate. Still, I really want to be able to handle ROM cycles with the SQI ROM, So I'm hopeful that I can devise enough tricks including hand assembled SQI protocol, falling edge clock tricks, and as a last resort, over clocking to make ROM timing. Especially since I won't have the option of a hold signal. Before I fab this board, I plan to put my logic analyzer on a real cart and characterize the typical cycle timings at the cart slot. I'm suspecting I may be losing a sliver of time budget over the timing diagrams due to the console having to decode to generate the ROMG signal. Right now I'm designing a Nybble-Slicer from 8:4 muxes so I can present most of the address nybbles directly to the SQI interface instead of piping them through the MCU. Most of the overhead will be in generating the high order address nybbles and getting them piped to the SQI as there will be a Port read, table lookup, and pointer arithmetic before the bank portion of the address can be sent. I guess the table lookup offset will be in a local variable by then, so at least I won't have to take the array index timing hit. All of this active discussion is great! I helps me "think out loud" while typing and alerts me to caveats I need to keep an eye out for. Thanks all
  8. Haha, thanks acadiel! Now the board is looking plenty sparse. I may throw down one EEPROM/FLASH socket just in case I can't make ROM timing. I came up with a trick that I'm sure will allow me to meet GROM timing however, maybe even at a crystal-less 8MHz. Stuffing options are always good
  9. OK, I had an 80% complete schematic for the design above with dual EEPROM sockets and all of the limitations I originally conceded to, but when I started some initial PCB floor planning I noticed that the cartridge board was looking pretty congested. Then, I realized that forgot all about the SRAM chip! Not willing to give up yet another important feature, I decided to scrap the whole thing and start over at the architecture phase So, now I'm back with a new design. I've decided to take the plunge and go for a unified ROM resource. I'm using a Quad SPI capable tiny 8-pin SOIC that packs up to 8MB in a single tiny chip! My hope is to make a very efficient "Byte-Bang" SQI interface implementation using AVR assembly so I can hopefully achieve the 4X speedup over 1-bit SPI. I'll have to see how fast back to back port writes can be done in assembly. I'm not at all worried about GROM, since that is slow as molasses(less than half a MHz clock, right?), but I really want to be able to handle straight ROM on this interface as well. I'm upsizing from a 20-pin AtTiny SOIC to a 32-Pin AtMega and putting an external crystal down. Worst case I'll over clock the AVR from 20MHz to 30Mhz which appears to be quite stable for most who have tried. Since I'm not using the ADC or any of the internal I/O modules really, I expect to be in good shape. This will prevent me from having to level shift an Xmega processor. Also, I'll be able to use some sort of serial in system programming method for the flash, instead of dealing with socketed EPROMs. This would open the door for a future revision with an AtMega USB capable AVR and being able to flash over USB, or I may just release some USB/UART based "bus-piratey" type flasher for those who want to be able to flash their carts. For first proto, at least, It'll have to be ISP through a custom external device like my MBED development board expansion port. Anyway, I just wanted to update everyone and let you know the project is officially underway! The PCB is holding up a couple of prototype multi board panels I'm waiting to release, so I'm motivated to get this one done quickly so I can send everything out at once and have a ton of fun soldering/reflowing to do in a few weeks
  10. Hi Acadiel, Thanks for the kind words and ideas! To get things rolling quickly on a prototype, the AnyCart is going to have some limitations. It's goal is to be able to handle most if not all production carts and early 3rd party carts, while being capable of handling many later titles. It really won't be able to easily accommodate new titles with ROMs exceeding 1-4 banks or >40K of GROM in one title. I'm sort of redefining the original latched bank switch scheme into a title selection, but after a title has been selected and launched, the AnyCart will allow titles that had limited bank switching via the writes to >600x to operate based on flags in the descriptor. Titles that did not actually implement bank switching, but instead did writes to ROM either due to bad code, or for copy protection, will have the live bank switching disabled. Oh, and also, SRAM! I'm putting an 8K non-volatile SRAM down that - needs no battery - So it will last forever(or at least one million power cycles with a data retention of 100 years). Mini memory should easily be able to be handled by the AnyCart, as well as new titles having a similar option of 4K ROM, 4K SRAM, or live banking of 8-24K ROM + 8K-ish SRAM. The only restriction is that you won't be able to use the lower maybe 256 bytes of the SRAM since writing there might switch the bank. It depends on how deep into address decoding I want to get into. My plan is for the AnyCart hardware to be cheap and easy. It will have 512K of ROM Flash and 512K of GROM flash split into 8K chunks. You will be able to select up to 128 titles, however, unless you were loading the cart with exactly 64 8K ROM only titles plus 64 8K GROM only titles, you probably won't e able to take advantage of the full 128 titles. However, there is a 1Mx8 OTP EPROM that seems to be pin compatible with the socket layout so I will try to have a jumper option to support that chip in case one is willing to give up reflashability for 2x the space. That 1Mx8 is the largest capacity that comes in 5V, and is not a pesky wide TSSOP which makes external programming and socketing a chore(and expensive!). I'm actually still trying to figure out the whole CRU mechanism, let alone using it for bank switching. I just want to "get" what it actually does. I realize it's some sort of serial based device register access as opposed to having memory mapped I/O in the parallel bus space(I think), but beyond that it's still a mystery. This is mostly because I haven't had time to do more than skim the available information on this bus. For me personally, it helps to have background information on WHY TI used this method this and not just how it operates. For the AnyCart, I probably won't have CRU style bank switching in at least for the initial prototype. Hopefully this will not exclude too many titles. I realize my AnyCart really will be an "Almost AnyCart", but that just doesn't roll off the tongue as easily, so I'm just gonna keep calling it the AnyCart My plans for the EveryCart, if I still have the time and resources to develop it in the future, will be to use a much more capable MCU like a 100Mhz Cortex M3. It will utilize a very fast and large unified SPI flash for all resources. The SPI will have to run at at least 33Mhz, I believe, in order to be able to meet ROM timing.The AnyCart's MCU is just a traffic director, intercepting a small number of address and control lines and staying out of the way of the data bus, while generating the appropriate base addresses and chip selects. The EveryCart's MCU is going to have access to the entire slot's signals and all will have to be 5V-3.3V level shifted. Access to everything on the bus, will make it much more powerful. Also, since the processor core will be 32-bits wide and be very fast, complicated math can be done on the address pointers so the memory resources can be utilized much more efficiently. A 6K GROM will only take up 6K, and, if anyone took the time to see how much actual space the carts take up(to the nearest 1K perhaps), we could optimize even further. I would be curious to know even for the AnyCart, if there are a large number of known titles that are actually 4K and under as it wouldn't be too difficult to partition at that granularity. Anyway, after much agonizing over memory chips, and trying my best to shoehorn SPI or SQI onto the AnyCart to make programming easier, I finally realized I'm going to have to start with the good ole 32-PLCC form factor socketed Flash/EEProms for this cart. I wanted a board that I can assemble reasonably easily with my tiny reflow oven and maybe a couple of partial solder stencils, if not solder completely by hand(Through hole and SIOCs). Since the surface mount 32-PLCC sockets are much easier to route, I'll probably be solder pasting and reflowing the AnyCart boards. If this thing really starts to sell, I'll invest in a full board solder stencil or maybe even offload assembly to the PCB fab house. These are going to come in new - repurposed cartridge shells, and I even had a plan to have a special edition that would come in new old stock retail boxes with a printed manual. First things first, though! With component selection complete, I'll be starting the schematic today
  11. Thanks for the offer! Actually, I have a TOP853 programmer for DIP parts and a PLCC socket to DIP adapter board. I also have an Atmel ICE for doing AVRs and I've completed design for a very useful MBED dev platform which will have an expansion SPI/I2C port. I'll use that for programming serial flash over SPI. My end goal is to be able to eventually program over USB via an AtMega with a USB boot loader, but the first prototype will have a PLCC socket for EEPROM(Actual 39F series flash that is pin compatible with the older 28C EEPROMS) and an AtTiny or a non-usb AtMega processor. I'm doing embedded design for a living now, so I have an arsenal of dev tools, programmers, and decent test equipment to aid in my development. Still, it's good to know there are otter resources out there. I may issue a beta cartridge for folks who are willing to do some QA and bug reporting.
  12. I guess was linked to the initial pages of the F18A project where the scope was just to make a better TMS9918A drop in. Still, having another 9900 on the VDP side while giving faster access to the VDP RAM, still has the bottleneck to the rest of the console. At some point the original TI console is just a dumb terminal to a faster secondary computer regardless of which bus it sits on. I'm with you on the nostalgia kick. That's why I'm happy to just work on a multi cart for the time being. If you're interested in ARM programming that is closer to bare metal, you might want to check out the MBED LPC1768 module. That will get you closer to the hardware than a RPI running linux, but Im not sure if the online MBED compiler will do inline assembly. My cartridge is simply going to be a more capable multi cart in that it will allow a much larger number of GROMs to be present, and will allow any mix of GROM, ROM, and RAM(4K or 8K) that existed in any production or 3rd party cart as well as whatever any new title desired for those resources (Up to certain constraints). It will also allow "live" bank switching for titles that had/need it, while blocking ROM writes for titles that used such methods for apparent copyright protection or just out of bad code. Basically, instead of writing a bank switch select to the address lines, you will write a "Title Select" value and the AVR will take care of selecting the ROM bank, doing or preventing ROM writes or live bank switching, and will emulate the GROM or multiple GROMs for titles that had such. I'm calling my first version of the cart the "AnyCart" as the goal is to be able to provide any cartridge that existed with no restrictions. However, I'm limiting this first version to 128 total titles based on the 512 byte EEPROM in the ATTINY I'm using and the belief that I will need four bytes for each title descriptor that outlines the resources needed for each title. The AnyCart will have a socketed EEPROM and the onboard flash will need to be SPI programmed with some semi-custom programmer. Also the AVR will need to be programmed with an ICE or similar. If I do well with the AnyCarts, I may go on to make an EveryCart, which will have much more space. Theoretically enough to cover 2^12 titles! And everything from the AVR to the GROM Flash to the EEPROM will be able to be programmed over USB either with a flasher program or if I can pull it off, a desktop mounted drag and drop system. The AnyCart is moving along well. I will complete selection of the memory chips and should have a schematic complete in a few days I have a ton of embedded and retro projects on a PCB panel, so I hope to add this by the end of the week and send it all off to fab by the Monday after next. You may also be interested in knowing that I have completed the design for a TI Speech ROM (TMS6100) ROMulator module. That project is actually for my 1980s Chrysler voice module custom messages project, but It may also be able to be applied to the TI-99 speech synthesizer. In fact I may use the TI-99 for some of my initial ROM testing! The chrysler module does not use the exact same chip, but I think they both use TMS6100 style ROMs and have compatible LPC encoding parameters. Some of my other Retro projects in flight include Timex Sinclair 1000/ZX81 Composite video boards that ft perfectly into the RF Modulator housing and several Adapters, disk emulators for the Apple II and Macintosh, but discussion of those should be opened on other forums once I get hardware back and tested.
  13. The F18A is sort of a special case in that it simply takes advantage of the fact that all of the video buffer is in it's domain so that it can process things like scrolling at it's own speed (100Mhz) and send output to alternative displays. The VDP doesn't execute 9900 assembly from what I know, so unless the F18A actually has a full 9900 emulator there will be no assembly speedup there. The bottleneck in the 8-bit VDP port is not just the data width, but the speed at which the console operates (3.xMHz) also. No matter how fast the co-processor is, you will always be limited by the speed at which the TI can feed the data or use the results. That's why I'm asserting that a 100Mhz ARM Cortex-M running bare metal code will be just as efficient as a 1Ghz Raspberry Pi running Linux for any useful application. In the example of wireless web page rendering, I would note that the secondary processor is simply hijacking the console's screen buffer. I would also assert that an LPC1768 M3 could fetch, render, and DMA to the VDP memory just as fast as the display driver would need for equivalent screen refresh rates. For hardware emulation in general, bare metal code or an RTOS will be much better than Linux especially since the TI's hardware timing will need to be adhered to. You're definitely right that the side port would need to be utilized for anything more fun than a multi-cart. My original wish was that I could add the 32K expansion and disk emulation in the multi-cart I'm designing. I really didn't have any intention of putting actual ports in a cartridge save for an SD card slot for disk emulation. If I were to work on any sidecar connected expansion, I would likely use a cortex M3 over a raspberry Pi. An MBED module would make development pretty simple. As it is, my project will be a multi-cart, with room for plenty of both ROM, and GROM images, as well as RAM, in whatever combinations are desired for any existing title as well as new title development, AND live bank switching like Extended Basic does and other carts might do will also be supported, AND carts that do "unnatural" live ROM writes will not mess up a running system as the AVR will be intercepting anything that strobes a write on the address bus as opposed to having the latches directly connected to the ROM bank select lines. I'm actually in progress as I type. I have a TI cart board outline template done in Eagle with the proper fingers for both sides of the board and a schematic symbol with the signal names assigned. I'm choosing Flash and EEProm memory components next.
  14. I totally get what goes into emulation. That's the difference between it and simulation. I can't speak to how Ed Schwartz implemented GROMs in V9T9, but I've been playing with emulators since the early 1990s and there were a lot of pure emulators that ran well on my 68030 and 68040 macs and even more that ran well on the first generation of PowePC processors. I've been a huge fan of Richard Bannister's work from way back. Also, I have a great understanding of proper hardware description languages as I worked on ASIC designs for nearly 10 years in both VHDL and Verilog. I'm not sure if anyone writing emulators has any background in that, but I believe that an emulator written in an event driven method similar to how HDL simulators are implemented, will end up with a more compact, easy to follow, and more efficient emulator. I'm sure large parts of most emulators are written in a similar way. Still, my point stands that it is very likely that Raspbian is getting in the way of speedy emulation in the case of the RetroPi suite. Theres no reason why a near 1Ghz ARM can't emulate a 1Mhz Apple IIe at speed. If you personally worked on the TI emulation in MESS, I'm certainly not knocking your work. If anything I'm blaming the OS and the driver structure of multi-emulators. You would probably hate what I did to my source copy of MAME. Since I'm only interested in Pre 1990 games, I gutted the drivers and stripped out unneeded processors and hardware to make my own MAME "Lite" for both the Palm OS5 and Mac OS-X. My current binary is only 15MB as opposed to the 100+MB original binary. I can probably get it down to below 10MB when I'm done. It's not about saving space. Gigabytes are cheap. I just like my software "lean and mean" OK I'm going to steer this thread back to TI multi-cart construction by actually attempting to make some progress in the next couple of weeks
  15. Oh, I have no problem believing that. The Apple II emulator that is packaged with RetroPi is awful! And that's just trying to emulate a simple 8-bit 1Mhz system with nothing as convoluted as as the 99's VDP. Consider, however that Ed Schwartz's V9T9 ran at full speed on a 486/66DX under DOS. That was sort of my point I was trying to bring light to. I suspect that because of the amount of diverse hardware that MESS supports and it's way of "driverizing" multiple platforms, it's probably not the most efficient emulator. I've been deep into the guts of MAME and how it emulates, so I suspect MESS is very similar. Still, when my 700Mhz 1st generation Pi can't emulate a dedicated Apple IIe emulator anywhere near at speed, my suspicion is that Linux(raspbian) is getting WAY in the way. That's why one of my winter software projects will be to port the emulators in RetroPi to be able to run closer to bare metal. My aim is to make a launcher that runs bare and to create C-libraries that perform some of the various linux graphics and input libraries so that newer versions of the emulator code can be later be re-compiled without needing to change the sources significantly. Also, I want to make a gameboy sized platform that can tun the same suite on a 3.5" screen with only an ARM Cortex M3 or M4(If I find that the emulation needs hardware FPU for things like vector graphics emulation or similar). Again, many people like that the Pi is cheap and they like/are familiar with Linux programming. Or, maybe they aren't and Linux allows them to just ./confgure, make other sure code with relative ease, but I like to find counter solutions to the mantra of "just buy the Pi2, it's faster" and find ways of getting more performance out of the current or lesser hardware since I know what the 16 and 32-bit older architectures were more than capable of emulating even at only 66-133MHz.
×
×
  • Create New...