Moderators: Mug UK, Zorro 2, Greenious, spiny, Moderator Team
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!
Steven Seagal wrote:For instance, what are those trapeziums called "SAB"?
Steven Seagal wrote: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?
...
I don't know if you plan to release some analysis in the near future,
why are there visibly two counters for the horizontal sync generator, HSC and HSCB?
Steven Seagal wrote:One last today: what could be the ubiquitous PORB?
ijor wrote:Steven Seagal wrote: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.
Steven Seagal wrote: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 wrote:Yep, it is easier to read schematics
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.
Steven Seagal wrote: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.
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.
troed wrote:Is this not exactly what I've deduced before? It's nice to see it confirmed by the schematics of courseIt'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 wrote:Do the DPR/DPS flip flops always induce a clock delay between input change and output?
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.
ijor wrote: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.
Steven Seagal wrote: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 wrote:As I keep saying, there are all sort of delays in hardware.
Users browsing this forum: No registered users and 8 guests