Jump to content
IGNORED

F18A DIY?


Hans23

Recommended Posts

  • 2 weeks later...

Annoyingly, the FPGAs have still not arrived, so I'm unable to build any more F18As right now.  I hope that they get through customs in the next days, but it seems that they are being looked at much closer than other stuff that Aliexpress shipped to me and that has already arrived.

 

Anyway, in the mean time, I have looked at how to get sound output from a machine with an F18A - this topic has certainly been covered before, but I'd like to summarize it for those folks who are late to the party like myself:  Sound is coming out of the AV DIN plug on the back side of the TI - even when the F18A is fitted.  With an NTSC console, all it takes is a DIN5 to RCA adapter cable which should be easily available.  The pinout is like this:

 

image.thumb.png.cb43c03995d9dba939fd65d465b2ce6d.png

 

Annoyingly, the PAL console uses a 6 pin 270° jack, and ready-made cables are not available for that.  The best solution is to replace the 6 pin jack by the standard 5 pin version, which has a compatible footprint.  In addition to replacing the jack, one also needs to rewrite a jumper to correctly connect the ground pin.

 

Here is a photo of the PAL version:

 

20210317_174615.thumb.jpg.1248d1bed622d2676fb892c2a173e858.jpg

 

Here is the same detail on the NTSC version:

 

20210317_174754.thumb.jpg.fe79c2192df4f88ba1e1f39ac71ed6db.jpg

 

I have a couple of these jacks and can send them alongside the F18A to owners of PAL consoles that want to make this conversion.

 

Cheers,

Hans

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Hans23 said:

Annoyingly, the FPGAs have still not arrived, so I'm unable to build any more F18As right now.  I hope that they get through customs in the next days, but it seems that they are being looked at much closer than other stuff that Aliexpress shipped to me and that has already arrived.

 

Anyway, in the mean time, I have looked at how to get sound output from a machine with an F18A - this topic has certainly been covered before, but I'd like to summarize it for those folks who are late to the party like myself:  Sound is coming out of the AV DIN plug on the back side of the TI - even when the F18A is fitted.  With an NTSC console, all it takes is a DIN5 to RCA adapter cable which should be easily available.  The pinout is like this:

 

image.thumb.png.cb43c03995d9dba939fd65d465b2ce6d.png

 

Annoyingly, the PAL console uses a 6 pin 270° jack, and ready-made cables are not available for that.  The best solution is to replace the 6 pin jack by the standard 5 pin version, which has a compatible footprint.  In addition to replacing the jack, one also needs to rewrite a jumper to correctly connect the ground pin.

 

Here is a photo of the PAL version:

 

20210317_174615.thumb.jpg.1248d1bed622d2676fb892c2a173e858.jpg

 

Here is the same detail on the NTSC version:

 

20210317_174754.thumb.jpg.fe79c2192df4f88ba1e1f39ac71ed6db.jpg

 

I have a couple of these jacks and can send them alongside the F18A to owners of PAL consoles that want to make this conversion.

 

Cheers,

Hans

 

I have cables for just audio on a pal in my store

 

  • Like 1
Link to comment
Share on other sites

Hi,

 

as I'm progressing with F18A builds, here is some additional information that may help if you're trying to do the same:

 

Matthew's original PCB layout on CircuitMaker.com is missing a trace to one of the voltage regulators.  I've patched the first bunch of boards that I built, but I have now fixed the layout. The Gerbers for that version are in this file: F18A_rev_B_-_Hans_Gerber (1).Zip.  A version of the BOM is available in this Google Doc.

 

The four 2mm pitch jumpers can all be connected to ground if the device is used in a TI-99/4A.

 

Instead of programming the Flash chip using JTAG and a Xilinx platform cable, one can program it using a suitable programmer and adapter (e.g. the TL866II+).  The binary file that goes into the ROM is attached here: f18a_250k_v19.bin.  Going this route will prevent you from having to get the ancient Xilinx ISE 14 development system to work.

 

Cheers,

Hans

  • Like 4
  • Thanks 4
Link to comment
Share on other sites

Got my boards from JCLCPB and all the parts DigiKey.  Lets see if I can pull this off like Hans.  Looks like boards came in with the missing trace, odd.  JLCPCB does not stock the FPGA, otherwise I'd have then do the SMT like I do for the TIPI/32K.  I may have an extra bare board or two if anyone else want to try the DIY route. 

 

image.thumb.jpeg.8affba8c1269aba30fd807ec4a029e8b.jpeg

 

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

More than once, I have considered dissecting the F18A's VHDL, then concocting a bastard daughterboard that implements the logic using a bunch of inexpensive (but fast logic speed) EEPROMs, using TTL logic approaches. That would completely remove the FPGA from the BOM, and replace it with a bunch of EEPROMs, resistors, and discrete output transistor packs.

 

Sadly, it would make the resulting device many time larger, and draw significantly more power.

 

I keep telling myself "No, that would be silly." to talk myself out of it.

  • Like 2
Link to comment
Share on other sites

On 3/21/2021 at 10:26 AM, wierd_w said:

... I have considered dissecting the F18A's VHDL, ...

Rather than dissecting the HDL, why not just ask me questions directly?  I'm more than happy to discuss any retro computer circuit board, IC, FPGA, or F18A internals.

 

On 3/21/2021 at 10:26 AM, wierd_w said:

... that implements the logic using a bunch of inexpensive (but fast logic speed) EEPROMs, ...

I don't think you could pull it off if you were trying to cover the entire F18A feature set.  Even the 9918A functionality would be pretty hard.  It would get pretty expense really fast, I would think.  The FPGA you are trying to replace is only $20, so that would be your price-point goal.

 

On 3/21/2021 at 10:26 AM, wierd_w said:

... using TTL logic approaches. ...

Retro arcade computers use discrete video subsystem with TTL chips, they are typically one full-size (18"x12", or so) PCB, and that only covers the tile, sprite, scrolling, and palette support.  VRAM and ROM are usually on another separate board, and a lot of systems also used custom ICs (with Williams blitter chips, for example).

 

On 3/21/2021 at 10:26 AM, wierd_w said:

Sadly, it would make the resulting device many time larger, and draw significantly more power.

You *might* fit such a system in the PEB - using *all* the slots.  It certainly would not fit inside any console, or be able to be powered from the VDP socket.

 

I'm not sure I understand the general push against FPGAs.  They are really just a bunch of TTL chips in a smaller package, and just as much fun to mess with.  I you look inside, you will find those TTL chips are pretty small too, and if you could remove all the packaging and stick them together at the wafer-level, along with some RAM to control some multiplexers, you would have something that looks like an FPGA.

 

An FPGA simply brings density and lower power, but inside it is still working the same way all those logic TTL chips work, and you still have to understand digital system design to get anything working with an FPGA.  It really is amazing how the physical TTL designs map directly to HDL.

 

It is also fun to learn how some of the old ICs work on the inside, and recreate that functionality in a way that it can be used again in real hardware.  The old chips are not going to be around or last forever, so we *have* to start migrating the design to more modern technology.  This is very similar to moving your data from paper, to tape, to floppy, so spinny-disk, to SSD.  Does anyone poo-poo loading a game (or other software) from an SD adapter of some sort, rather than from an EPROM in a cartridge?

 

To me, an FPGA allows one person with hobbyist-level skills to do what used to take a team of very educated and experienced engineers many months of work, and millions of dollars, to produce.  It is like a little personal IC fab on my desk.  Very much like how the "PC" (personal-computer) brought computing to the individual in their own home, rather than having to go share a big computer with other people.

 

For me, the FPGA is not replacing the original hardware, it is preserving it at a level that is closer to the original hardware than you can get with software emulation.

  • Like 4
  • Thanks 1
Link to comment
Share on other sites

[why not just ask directly?]

Because I can convert the HDL directly into circuit logic, with patience and time, and dont have to distract you from your current project.

 

 

 

Not so much that I have a push against them; The issue is that they get obsoleted quickly, and then the project can no longer be reliably built. EEPROM is a commodity item, however-- at worst, there is a lead time on ordering in bulk.

If the device has reached feature maturity (and thus is unlikely to need to be field reprogrammed with patches in the future), then devising a replacement is desirable, as it allows the device to be build reliably in the future, without having to hunt down dwindling supplies of 'no longer manufactured' stock.

 

But, I think you are misunderstanding a bit.  EEPROM chips are essentially just mini gate arrays.  For arbitrarily raised address lines, they output arbitrarily raised data lines. (based on what you program onto it.)  They can therefor be made to half-assedly do the job of things like PALs/GALs (with a LOT more input potentials), and if you sequence enough together, you can even make CPUs out of them. 

 

(Rather than run them on a communal address bus structure, and call them with a chip select line, like is intended for them, you always raise chip select on every chip [so it is always waiting for its address lines to change, so it can return its data bits on its data lines], and then use the data outputs of previous chips to drive address lines on downstream chips.  This way the chips function like programmable logic, rather than memory.)

 

In this case, I was going to hunt down some very large EEPROMs. 

This one from mouser is 16bits wide on its address space, and 8 bits wide on its data IO, for instance.  That is not bad; that is a 64kb EEPROM.

https://www.mouser.com/datasheet/2/268/doc0010-1368926.pdf 

 

To determine how many I would need, I would need to fully dissect your HDL, and see every logic operation your FPGA is doing, and what logic is used to combine them. Fewer chips may be needed to implement, by creative use of chips with lots of address lines. (thus, the same EEPROM could be doing the work of multiple kinds of logic chip, as long as that chip does not have to do more than one logic operation per cycle. You use the large number of address lines in the big end, to define the logic operation to be performed-- then the lower address lines are the logical inputs to process. The chip returns the result on the data pins. The same logic that drove the selection of the logic operation to perform, can control connecting the data pins to the correct downstream circuit that needs the logic done.) The million dollar question would be if the resulting assemblage could meet the operation clock-times needed to do the job. (that much I very much find suspect.)  Perhaps if I moved away from DIP package (for working theory), and toward the more expensive surface mount 4mbit density modules, fewer would need to be sequenced together, and total clock time would be doable.. but ...

 

Again, I tell myself "no, that is silly."

 

The TTL portion of the circuit, is just how the EEPROMs would talk to each other to get combined logical outputs.  The logical state of the data pins of one eeprom, determines the address lines of subsequent eeproms, in a TTL-like manner.   For this to work, the packages *MUST* be parallel interface type eeprom, and not serial eeprom.  I am not implying "Build the whole thing out of actual GAL/PAL chips!".  That would indeed need something the size of a PEB.  Instead, I can get the same number of transistors to do logic with out of modern programmable rom chips, in a fraction of the space.

 

 

 

 

 

Link to comment
Share on other sites

10 minutes ago, wierd_w said:

To determine how many I would need, I would need to fully dissect your HDL, and see every logic operation your FPGA is doing, and what logic is used to combine them.

You can get a faster estimate by looking at the synthesis report and seeing how many LUTs it used, since that's essentially what you plan to implement. It won't be precise, but it will get you in the napkin-estimate range.

 

  • Like 1
Link to comment
Share on other sites

15 minutes ago, wierd_w said:

The issue is that they get obsoleted quickly, and then the project can no longer be reliably built.

I'm not sure where this perception comes from, but I don't find this to be true most of the time.  The Spartan-3E, that the original F18A uses, was introduced in 2005 and is still in production.  That is 16 years old.  In 2005 the 99/4A was only about 23 years old, so the Spartan-3E is not doing too bad in comparison.  And, being a lower power device, the FPGA will probably last longer, plus it is based on SRAM so it does not suffer from write-durability problems like flash devices.

 

Also, you realize you are talking about obsolescence in the scope of a retro computer that is using parts that have been out of production for decades?  If I wanted to make a 99/4A today, where can I buy a 9900, 9901, 9918A, 9904, and the GROMs?  Aside from new-old stock and used parts, you can't get those parts.

 

Anyway, my counter-point is, FPGAs tend to have very long production runs due to their primary markets, i.e. automotive and aerospace, which demand longevity.  And, once your parts get certified for something like automotive or use in space, they tend to be used for decades.

 

25 minutes ago, wierd_w said:

To determine how many I would need, I would need to fully dissect your HDL, and see every logic operation your FPGA is doing, and what logic is used to combine them.

Just having the logic formulas does not mean it can be stuffed into a sufficiently sized memory to achieve the functionality.  What is missing from the formulas are the registers that can feed into the system to affect the state.  Without some sort of storage you have to essentially encode every possible state of every variable.  This gets out of hand really quickly with even just a few 8-bit registers.  You should try to do a few simple test circuits to see how far you can take it.  Just implement the two primary counters needed to sync a video display, or something like that.

Link to comment
Share on other sites

Crap, I missed this thread for some reason.  I really need to get the parts and build one.


Gotta get over my hate of SMD soldering first, though.  As well as a backlog of pulse to DTMF boards that are sitting waiting to get built as well as a 1A2 repro KSU.

 

  • Like 2
Link to comment
Share on other sites

11 minutes ago, acadiel said:

Crap, I missed this thread for some reason.  I really need to get the parts and build one.


Gotta get over my hate of SMD soldering first, though.  As well as a backlog of pulse to DTMF boards that are sitting waiting to get built as well as a 1A2 repro KSU.

 

The SMT soldering isn't so bad until you hit a semiconductor. And then I panic.

Lol

Link to comment
Share on other sites

19 hours ago, wierd_w said:

But, I think you are misunderstanding a bit.  EEPROM chips are essentially just mini gate arrays.  For arbitrarily raised address lines, they output arbitrarily raised data lines. (based on what you program onto it.)  They can therefor be made to half-assedly do the job of things like PALs/GALs (with a LOT more input potentials), and if you sequence enough together, you can even make CPUs out of them. 

 

(Rather than run them on a communal address bus structure, and call them with a chip select line, like is intended for them, you always raise chip select on every chip [so it is always waiting for its address lines to change, so it can return its data bits on its data lines], and then use the data outputs of previous chips to drive address lines on downstream chips.  This way the chips function like programmable logic, rather than memory.)

I'm pretty sure he's not misunderstanding -- replacing one FPGA with a litany of EEPROMs is impractical at best. Most FPGAs remain on the market for quite a long time, and the task of reworking a board to use a different one would be far easier than designing this hypothetical, comically large EEPROM-based board. Parallel EEPROMs themselves are going out of style; Mouser only shows 13 different parts in stock in your suggested size.

 

More importantly, EEPROMs are a poor substitute for programmable logic at the speed of the 9918A/F18A. The access time of 120ns for the part you linked (which is typical for EEPROMs of that size) means it'll take 120ns for the output data to be valid after an address change; by extension, a chain of 4 EEPROMs cascaded would need 480ns for the output to be valid, at which point you're almost certainly violating the timing requirements of the 4A.

  • Like 1
Link to comment
Share on other sites

Yes. I did in fact shine a light on that myself.


 

Quote

 

The million dollar question would be if the resulting assemblage could meet the operation clock-times needed to do the job. (that much I very much find suspect.)  Perhaps if I moved away from DIP package (for working theory), and toward the more expensive surface mount 4mbit density modules, fewer would need to be sequenced together, and total clock time would be doable.. but ...

 

Again, I tell myself "no, that is silly."

 

 

EG, "I acknowledge that the very premise is silly", and "The chips in question are not really fast enough to do this in series anyway, most likely."

 

 

Link to comment
Share on other sites

21 hours ago, wierd_w said:

and toward the more expensive surface mount 4mbit density modules

...and as far as I was able to tell, the parallel 4Mbit parts are listed as "Obsolete, Not Recommended for New Designs" on virtually all major electronics distributors, whereas the Spartan is still active and in stock.

 

There's no question about whether such a thing will work; an EEPROM approach straight-up will not work in the 4A.

Link to comment
Share on other sites

Slow progress, but almost there.  SMT soldering isn't that bad, just need patience and some good flux.  Only part I couldn't get from distribution was the NOR SPI Flash.  Still have a couple of extra bare boards if anyone wants one.

 

IMG_0252.thumb.JPG.dc5a7bbb666fa53b01940d28730ed43e.JPGIMG_0251.thumb.JPG.9e4f76013b0430c88abdaa3ba8a3682e.JPG

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...