How I found some original Atari ST ASIC designs

[czietz]

These DWG files are not in the AutoCAD format. They were created by a CAE software called FutureNet DASH, that also uses the DWG extension but a completely different file format.

[denial]

Oh great, by the end of the 90's they were giving away FutureNet for free and there was even an official documentation of the file format.
But all of this appears to have vanished from the internet.

[TheNameOfTheGame]

Might help to find this guy.

[czietz]

Yes, I found his webpage a few hours ago and sent him an e-mail.

[TheNameOfTheGame]

Contacted Paul Schoen and he was generous to provide the Futurenet files. Not sure if they will work with XACT, but at least we can try.

https://www.dropbox.com/s/bze8nx5i7bctjmq/DATAIO.zip

https://www.dropbox.com/s/tbva7hcam4rth4i/DPLOT.zip

Please let me know if they work for this project and big thanks to Paul....You rock!

[czietz]

Thank you, also to Paul Schoen, of course!

This version of FutureNet can indeed open the Atari drawings. I will try and see if with the software I can recover a bit more from the corrupted ones.

More importantly: The included plot program creates HPGL output from the drawing, so I can preserve the drawings as vector graphics and not only as this pixelated printouts I get from the setup described in my article.

[TheNameOfTheGame]

Paul has offered an additional tool that may help with the corrupted files.

Jeff:
I also found an old Borland Delphi (D4 Pro) project that can read Futurenet files and display them on screen. It also converts them to a text format. And a related project converts the DWG file to a Mentor Graphics PADS Logic SCH format, but it is only a partial conversion. I have bundled the Delphi project files along with the executables, and some sample Futurenet files that I used for testing. Use them in any way you wish; perhaps they can help restore the corrupted files.

http://enginuitysystems.com/files/FNread.zip

If you'd like to use Delphi to continue work on this project, there is a D4 standard version on eBay for $40:
http://www.ebay.com/itm/Borland-Delphi-Standard-4-0-CD-ROM-With-Manual-Chart-Keycode-/131916749531?hash=item1eb6d9dadb:g:pwEAAOSw0UdXu2kI

Best of luck!

Thanks Paul! I hope it can help with the corrupted files.

[czietz]

Yes, also thanks from me! Will have a look later.
I even have (a more recent version of) Delphi.

[Steven Seagal]

Hi
Has somebody analysed the schematics for the GLUE-MCU?
Did I miss the thread?
I've started doing it but not being in the field, I've more questions than answers...
For instance, what are those trapeziums called "SAB"?

[ijor]

For instance, what are those trapeziums called "SAB"?

It is a mux, it selects between input A and input B.

[Steven Seagal]

Thx. Funny but my google searches didn't deliver.
Do you reckon the schematics are precise and complete enough to write a GLUE-MCU video logic for emulation?
Too bad the STE Shifter is still a black box.

I don't know if you plan to release some analysis in the near future, in that case there's no point in my bothering you with naive questions right now.
If you don't, I have one, among many: on sheet 26, why are there visibly two counters for the horizontal sync generator, HSC and HSCB?

[ijor]

Thx. Funny but my google searches didn't deliver.

Don't know if it is supposed to be in Google. But the trapezium shape is the standard symbol shape for a mux.

Do you reckon the schematics are precise and complete enough to write a GLUE-MCU video logic for emulation?
...
I don't know if you plan to release some analysis in the near future,

I assume it is is precise and complete, but I can't say for sure. I don't plan releasing any analysis anytime soon. I am not so familiar with the STE (as opposed to plain ST/STfm) architecture in the first place.

why are there visibly two counters for the horizontal sync generator, HSC and HSCB?

It is just one and the same counter, only that one is inverted. It is much easier for the hardware to compare if you have both the positive and negative values of each bit. If you check the comparators in the same page, you'll see that they use a simple AND gate. Otherwise you need to combine XOR gates which are much more expensive in hardware.

[Steven Seagal]

OK thx, it starts to make sense.
There's also MDE1 and MDE1B for example: bit 1 of shift mode set and cleared respectively.
I'll try to match this sheet with your pseudo-code for HSYNC and come back with more questions.
One last today: what could be the ubiquitous PORB?

[czietz]

Generally, in these schematics: POR = "Power On Reset".

Oh, and to answer a question I was asked this recently via e-mail: why do the muxes have two selection inputs (SA/SB) that are complementary? Answer: It comes down to the way the muxes are (most likely) implemented at transistor level. See http://cmosedu.com/jbaker/courses/ee421 ... _schem.PNG. It also has two select inputs (S/Si).

[ijor]

One last today: what could be the ubiquitous PORB?

As Christian is saying, it stands for POWER ON RESET. This signal is supposed to be asserted on coldstart, and only on coldstart. But since uses some non-standard digital trickery, I'm not sure how reliable it is. Some tests performed by czietz confirm that, at least on STf's MMU, it doesn't work on every power up. It is non fatal if this happens.

[Maeke]

Thx. Funny but my google searches didn't deliver.

Don't know if it is supposed to be in Google. But the trapezium shape is the standard symbol shape for a mux.

Depends on where you live, in french school i had to learn a different symbol system, can be very confusing when you want to understand Atari's shematics if you don't know about this difference.

Here is an example http://philippe.berger2.free.fr/automat ... inaire.htm

[Steven Seagal]

So I could match the horizontal sync generator schematic on sheet 26 with some of ijor's pseudo-code (values 101, 111, 121, 127...).
Guess it's easier with the blueprints than looking directly at the chip.
But on the right of the "comparators", there are rectangles called DPR and DPS. Once again I cry for help, can't find anything on google.
Reset, Set?
While we're at it, I also don't grasp the kind of feedback on the right of this with the two OR gates.

[ijor]

Guess it's easier with the blueprints than looking directly at the chip.
But on the right of the "comparators", there are rectangles called DPR and DPS. Once again I cry for help, can't find anything on google.
Reset, Set? While we're at it, I also don't grasp the kind of feedback on the right of this with the two OR gates.

DPR and DPS are synchronous flip flops with async reset and (pre)set respectively. The circuit at the output with the two NOR gates is an SR-latch. That's the register that actually holds the state of the internal HSYNC signal.

Yep, it is easier to read schematics

[Steven Seagal]

Yep, it is easier to read schematics

He he

DPR and DPS are synchronous flip flops with async reset and (pre)set respectively. The circuit at the output with the two NOR gates is an SR-latch. That's the register that actually holds the state of the internal HSYNC signal.

Thx again...
Do the DPR/DPS flip flops always induce a clock delay between input change and output?
If yes, that could explain some latency between comparisons and signals, and can be traced on the schematics.

I also checked the Sheet 29, Horizontal DE / BLANK counter.
There's a breakthrough in some old mysteries. As we know the "DE" decision is made earlier on the STE than on the STF because of possible HSCROLL.
If there's no HSCROLL, or the STE is in medium resolution, Shifter prefetch is delayed, by using those DPR/DPS flips flops.
By 4 cycles for no HSCROLL in high res, by 8 cycles for HSCROLL in med res, by 16 cycles for no HSCROLL in low or med res.
If you switch to low res after the DE decision has been made in high res (emulator cycle 2), but before the delay for high res is finished (emulator cycle 6), the GLUE keeps on delaying for 16 cycles.

This is the real explanation for the line +20 trick at emulator cycle 4, and a great day for emulation as far as I'm concerned, because we spent much time pondering on it.

Another amateur discovery, to be confirmed, apparently if you switch to high res on a colour monitor, the rest of the line will be blanked. High res sets BLANK whatever the counter. Maybe to protect the screen. That's why BLANK only acts on colour screen. On a monochrome screen it would be black all the time.

[troed]

There's a breakthrough in some old mysteries. As we know the "DE" decision is made earlier on the STE than on the STF because of possible HSCROLL.
If there's no HSCROLL, or the STE is in medium resolution, Shifter prefetch is delayed, by using those DPR/DPS flips flops.
By 4 cycles for no HSCROLL in high res, by 8 cycles for HSCROLL in med res, by 16 cycles for no HSCROLL in low or med res.
If you switch to low res after the DE decision has been made in high res (emulator cycle 2), but before the delay for high res is finished (emulator cycle 6), the GLUE keeps on delaying for 16 cycles.

This is the real explanation for the line +20 trick at emulator cycle 4, and a great day for emulation as far as I'm concerned, because we spent much time pondering on it.

Is this not exactly what I've deduced before? It's nice to see it confirmed by the schematics of course It's also the reason for the (so far not used by anyone I believe) +4 and +6 lines possible to create on STE.

From the writeup on the wiki:

The following pseudo code describes how PRELOAD gets handled:

Code: Select all

 WORDS_READ=0
 WHILE(PRELOAD == TRUE) {
   LOAD
   WORDS_READ++
   IF(RES == HIGH AND WORDS_READ=>1) PRELOAD = FALSE
   IF(RES == LO AND WORDS_READ=>4) PRELOAD = FALSE
 }
 H = TRUE

In regular HI resolution the routine will exit after four cycles (one word) and in LO resolution it will take 16 cycles (four words). This is what makes the STE timings for raised DE match up with ST. It's also why it's possible to create +20 (left border), +4 and +6 (regular) line by disrupting this code, according to the following:

Code: Select all

4: IF(RES == LO) PRELOAD will run until cycle 16 - (56-16)/2 = +20
44: IF(RES == HI) PRELOAD will exit after 4 cycles - (376-44)/2 = +6
48: IF(RES == HI) PRELOAD will exit after 8 cycles - (376-48)/2 = +4


Another amateur discovery, to be confirmed, apparently if you switch to high res on a colour monitor, the rest of the line will be blanked. High res sets BLANK whatever the counter. Maybe to protect the screen. That's why BLANK only acts on colour screen. On a monochrome screen it would be black all the time.

No, that does not happen. edit: I read it as meaning it would stay BLANK even after you switch back, which it doesn't. Maybe you meant if you keep running the line in HI though?

/Troed

[Steven Seagal]

Is this not exactly what I've deduced before? It's nice to see it confirmed by the schematics of course It's also the reason for the (so far not used by anyone I believe) +4 and +6 lines possible to create on STE.

From the writeup on the wiki:

The following pseudo code describes how PRELOAD gets handled:

Code: Select all

 WORDS_READ=0
 WHILE(PRELOAD == TRUE) {
   LOAD
   WORDS_READ++
   IF(RES == HIGH AND WORDS_READ=>1) PRELOAD = FALSE
   IF(RES == LO AND WORDS_READ=>4) PRELOAD = FALSE
 }
 H = TRUE

In regular HI resolution the routine will exit after four cycles (one word) and in LO resolution it will take 16 cycles (four words). This is what makes the STE timings for raised DE match up with ST. It's also why it's possible to create +20 (left border), +4 and +6 (regular) line by disrupting this code, according to the following:

Code: Select all

4: IF(RES == LO) PRELOAD will run until cycle 16 - (56-16)/2 = +20
44: IF(RES == HI) PRELOAD will exit after 4 cycles - (376-44)/2 = +6
48: IF(RES == HI) PRELOAD will exit after 8 cycles - (376-48)/2 = +4


Hi, it is hinting at the correct behaviour but it isn't satisfying as it implies that video memory is fetched without moving the video counter if there's no HSCROLL. Hence the WORDS_READ and PRELOAD variables.
In fact I don't see HSCROLL as a variable in this (Med res is also missing). The PRELOAD routine is executed no matter what and H is set at the same time with or without HSCROLL. I don't think that's correct.
On the schematics, the behaviour is different whether HSCROLL ($FF8265) is null or not.
With HSCROLL, H = TRUE sooner. H is necessary for DE, which starts prefetching.
Delays are added if HSCROLL is null, so that H = TRUE as if it were an STF.
Unless my reading is wrong, of course.

Another amateur discovery, to be confirmed, apparently if you switch to high res on a colour monitor, the rest of the line will be blanked. High res sets BLANK whatever the counter. Maybe to protect the screen. That's why BLANK only acts on colour screen. On a monochrome screen it would be black all the time.

No, that does not happen. edit: I read it as meaning it would stay BLANK even after you switch back, which it doesn't. Maybe you meant if you keep running the line in HI though?

/Troed

No, you read it right, but maybe I read the schematics wrong.

EDIT: of course, if BLANK is negated later in low res, around 28?, this is cancelled.
But if you remove the right border with a high res switch, it should be blanked... this could be a false discovery

[ijor]

Do the DPR/DPS flip flops always induce a clock delay between input change and output?

The output of a flip flop changes at the active clock edge. Assuming the input changes at the same clock and edge (it doesn't have to), yes, the output follows one cycle later.

Another amateur discovery, to be confirmed, apparently if you switch to high res on a colour monitor, the rest of the line will be blanked. High res sets BLANK whatever the counter. Maybe to protect the screen. That's why BLANK only acts on colour screen. On a monochrome screen it would be black all the time.
...
No, you read it right, but maybe I read the schematics wrong.
EDIT: of course, if BLANK is negated later in low res, around 28?, this is cancelled.

You actually read the schematics right, mostly. That 's interesting and is a different behaviour than the one performed by STFm GLUE.

STFm GLUE considers BLANK as a relevant signal for monochrome as well (even when at board level is not) and applies similar logic as for the color frequencies. Here, according to those schematics, high rez asserts BLANK regardless the horizontal position, as you are saying. Switching to color will not clear BLANK automatically, not until the counter reaches the correct value. So it depends at which point you switched to mono.

Note that SHIFTER blacks the RGB signals at high rez anyway.

[Steven Seagal]

The output of a flip flop changes at the active clock edge. Assuming the input changes at the same clock and edge (it doesn't have to), yes, the output follows one cycle later.

I was thinking about the DPR ref. PT030 in Sheet 29 that gets the "start line" decision as input.
The counter (NLCBN, etc.) and this DPR being clocked by the same line, when the counter matches it's too late to be output, the result is held until next clock. If that's true, then we find 4 CPU cycles of latency at this point.

[ijor]

I was thinking about the DPR ref. PT030 in Sheet 29 that gets the "start line" decision as input.
The counter (NLCBN, etc.) and this DPR being clocked by the same line, when the counter matches it's too late to be output, the result is held until next clock. If that's true, then we find 4 CPU cycles of latency at this point.

That's correct. As I keep saying, there are all sort of delays in hardware.

[Steven Seagal]

As I keep saying, there are all sort of delays in hardware.

Yes, but I thought all delays were quite arbitrary, this one is clocked, precisely to avoid some arbitrary drift I guess.
It's good news for me (in an emulation perspective)