That leaves the last piece to this puzzle. Now that we have the I/O card, CPU card, and graphics card figured out, that leaves behind the data card. 

The data card serves a few purposes in the machine, it also contains the audio circuitry. it contains the FM demods, the audio switching network, output amplifier and the warning tone generator. 

previously in the project we had already netlisted this board and created a schematic. 

This board is originally designed to demodulate the subcarriers from the satellite transponder. 

Once again, I decide to take a look at the ROM to figure out potentially what is going on with this card, and there is a patent available for the STAR 4000 which explains the data packet format, what all the different types are, and etc. the ROM pretty much follows the patent for the most part. 

Other interesting thing is, there are some stuff in the bottom of the ROM which im not sure what does, but its interesting: 

Some text values there used for something. the Data card has no serial in/out so it must be something that gets sent back to the 68K at some point over the FIFO. 

The architecture of the data card's design, basically has a single byte latch register for the 68K to be able to read, as well as one to be able to write. there is also a FIFO that is read-only by the 68K. 

so therefore, the 68K has two data registers it can read from the data card, and one to write back. There is also two audio registers the 68K can also write to, which can control the audio matrix. 

The other problem is, some of the audio stuff is also controlled by the data CPU. so the two have to work in tandem to control the audio stage. This is painful. THIS... is also why when a 4000 would go into alert mode, the warning tone appeared to have some "breakup"  in it. It is due to the fact the data card's CPU has to go off and do some other stuff handling incoming data which would cause the audio latch to de-assert in short bursts. Even though the 68K is keeping the alert tone enable line asserted during the entire duration. 

The data format at which it uses, they used the old legacy STAR 3000/Jr for text-based products at which the scripts would use and format to display on screen in a graphical manner, you can see this here in ROM with the data parser I had commented:

So this machine did, in-fact, use the old 37-byte Teletext frame format for controlling its products and parsing the OMCW to determine what is being displayed. 

This coincides with the release of the 4000 being all text based, mimicking the 3000's operation. It was easy for them to do. 

Anyways, a lot of effort would need to be put into conforming to, and formatting the data in a particular way if i were to use this data card.

Also, we need to build a satellite subcarrier encoder, and an SDLC framer. None of which I felt like doing. 

The satellite no longer exists anymore either. 

I could do what I did with the I/O card, and replace the ROM with my own since it too is also MCS51 based. Trouble is, I would still be stuck with SDLC framing with NRZI-FSK encoding. 

At the end of the day, we really needed to bring the data delivery system into the 21st century to work with our modern standards if we really wanted to use a 1980s machine with 2019 data standards. 

So? I voted for the nuclear option. forgo the entire data card and engineer a new one!