To infinity and beyond... (new hardware)

[+MrFish]

1 minute ago, Spaced Cowboy said:

"is" is something of a misnomer. "will be" would be more appropriate

Yeah... I meant the design your showing.

  

1 minute ago, Spaced Cowboy said:

But essentially, yes, that's right.

Alright, count me interested -- pending cost.

 

[+MrFish]

11 minutes ago, Spaced Cowboy said:

...4 following shortly afterwards...

Ethernet connecting to something like AspeQt/RespeQt would be useful.

 

[reifsnyderb]

This sounds like it would be a cool board for the 1090.

[+Spaced Cowboy]

1 hour ago, MrFish said:

Ethernet connecting to something like AspeQt/RespeQt would be useful.

I agree, but I've learnt my lesson on feature-creep. I'm doing what it says on the box, and anything else can come later

 

1 hour ago, reifsnyderb said:

This sounds like it would be a cool board for the 1090.

Well, to be fair, it started out as a replacement (of sorts) for the 1090  It shouldn't be too hard to adapt though, my (limited) understanding of the workings of the 1090 is that it's "just" a bunch of PBI interfaces, with the OS controlling the logic for which gets activated at any one time. Given the new design makes no attempt to take over the bus, it ought to work fine electrically, as soon as I have it working in the non-1090 instance.

 

I'll have to be a bit more careful regarding memory and signalling if there's any desire to get it to work in the 1090 though. The more normal use-case is "there can be only one" and all your base is belong to me. I'll have to be careful about $D100, $D101 and $D1FF which is no great hardship, to be fair.

 

I was planning on dividing up page $D1 into 16 sections of 16 bytes each, with each section defining the parameters for a memory aperture. Losing the top and bottom one is mildly annoying, but maybe I can squeeze those 16 bytes into a smaller section and still keep the aperture count high enough, or maybe 16 is way overkill - how many externally-sources memory regions do you really need at a time ?

[+MrFish]

1 hour ago, MrFish said:

Ethernet connecting to something like AspeQt/RespeQt would be useful.

 

12 minutes ago, Spaced Cowboy said:

I agree, but I've learnt my lesson on feature-creep. I'm doing what it says on the box, and anything else can come later

AspeQt/RespeQt (type of PC application) would be a software peripheral service over Ethernet. How would that be feature creep?

Currently, AspeQt/RespeQt emulates disk drives, printers, etc., via an SIO2PC cable. (in case you're unfamiliar; it's open-source too).

 

[reifsnyderb]

22 minutes ago, Spaced Cowboy said:

Well, to be fair, it started out as a replacement (of sorts) for the 1090  It shouldn't be too hard to adapt though, my (limited) understanding of the workings of the 1090 is that it's "just" a bunch of PBI interfaces, with the OS controlling the logic for which gets activated at any one time. Given the new design makes no attempt to take over the bus, it ought to work fine electrically, as soon as I have it working in the non-1090 instance.

 

I'll have to be a bit more careful regarding memory and signalling if there's any desire to get it to work in the 1090 though. The more normal use-case is "there can be only one" and all your base is belong to me. I'll have to be careful about $D100, $D101 and $D1FF which is no great hardship, to be fair.

 

I was planning on dividing up page $D1 into 16 sections of 16 bytes each, with each section defining the parameters for a memory aperture. Losing the top and bottom one is mildly annoying, but maybe I can squeeze those 16 bytes into a smaller section and still keep the aperture count high enough, or maybe 16 is way overkill - how many externally-sources memory regions do you really need at a time ?

We have been making progress on the 1090.  At this time, there is a working 1090 board, a working 80 column card, working 320k RAM upgrade card, and reproductions of the original RAM upgrades.

 

If there are any device drivers, you could have them in a ROM and have them automatically installed as per the 1090 and PBI specifications.  Using too much of $D1xx will break compatibility with other cards.  (i.e.  The 80 column board.)  Realistically, you have $D100-$D1AF. 

 

I am attaching a document I've been working on that explains the pinouts of the PBI, 130XE ECI, and 1090 as well as a bunch of notes and memory address specifications.  Sources are near the end of the document.  (The 1984 document is quite helpful, too.)  I started working on it after I found many problems with existing documentation.  (It's nowhere near finished but it may help.)  Depending on if and how you chose to proceed, you could use other memory regions for additional aperatures.

 

Below is also a working schematic of the 320k memory module for the 1090.  I am including it as it may help with details such as enabling the data bus and timing.  I've added the 1090 tech spec document as well.

 

If you would like to turn this into a 1090 card and have any questions regarding the 1090, please feel free to ask.

 

parallel bus document.pdf

 

schematic.pdf

 

1090_hardware_tech_spec-11MAY84.pdf

 

 

 

 

 

[+Spaced Cowboy]

1 hour ago, MrFish said:

 

AspeQt/RespeQt (type of PC application) would be a software peripheral service over Ethernet. How would that be feature creep?

Currently, AspeQt/RespeQt emulates disk drives, printers, etc., via SIO. (in case you're unfamiliar; it's open-source too).

 

What I mean is: I'm not planning on adding things to the 'to-do' list until the thing is done

 

If what you meant was "I, MrFish, could write something to make AspeQT/RespeQT work with this and it would be awesome", then I'd have to say "I agree, that's an awesome idea" 😀

 

Or if it's "The AspeQT/RespeQT people could do something awesome with this", again I'd have to agree I'm just not committing to doing it myself.

 

There's quite a bit to do to get this to work, off the top of my head and in very rough order:

• The 8-bit bus monitor needs to be written - I think I have some of this from the previous incarnation, but there's still more to do. I don't think I handled writing data back, notably, or a complete implementation of the memory aperture idea.
• Once that's working well, I need to handle read-requests (where the FPGA is driving the bus, not just monitoring it) within the memory apertures and drive the results onto the bus so the memory works. That means getting the PSRAM interface working within the FPGA. 
• Then the bus-monitor needs to parse out Antic memory fetches (I'm monitoring /HALT for this), and I need to write the code to handle basic display-list processing, bitmap-fetching etc.
• And I also need to monitor a variety of other areas - character-set address, colour registers, etc.
• Now I have a frame buffer building up, so I have to drive that out onto the HDMI interface. Got to figure out whether that'll be line or frame-based.
• So now we have a basic screen display, with all the supported Antic modes - then there's things like fine-scrolling registers, PMGs. and emulating it warts-and-all so that software that relied on the bugs in Antic actually works
• I'd also like to special-case things like alternate luma/chroma display-list lines, so actual colours show up correctly. Bonus points for blending. Artifacting detection/implementation would be a plus as well...
• Now I have to get the RP2040 microcontroller talking to the FPGA, which means writing PIO assembly to handle the bus interface on the RP2040 side and verilog on the FPGA side.
• Then write an ethernet driver for the RP2040, so it can connect to remote sites and get/put data. If I can create/use a standard BSD sockets-like interface then that will make this go a lot faster later on.
• Then I can get a protocol working for handling incoming/outgoing ethernet data between the FPGA/RP2040, and how that integrates with the XL side. There are a few cases here to manage
  • The XL actually requested some data (OPEN on N: followed by READ)
  • A remote peripheral wants to send data to the XL asynchronously, which means getting /IRQ working on the XL bus
• Then we get the remote side working and voila, remote services as "slots".
• When all that's done, and before I get to "release", I want a bullet-proof update-the-firmware routine. I've designed in a USB-hub and USB-switches so I can route the FPGA's JTAG-over-USB (in device mode) to the RP2040 (which can switch into host-mode for this), so in theory I can get the RP2040 to download to the FPGA or the SPI-flash on the FPGA board. I have to have that working before I release.

 

For something like RespeQT, I'm guessing a device driver wants to intervene between the OS and the remote IO, but if I do the rest correctly, I think it ought to be possible just to have a device driver be the same as any other access. The driver can do it's job of emulating a device and call the API methods I'll provide (for which I'll need registers perhaps). 

 

But there's quite a way to go before we get there, so I'm leery of saying *I* will do anything else  

 

The nice thing about the video is that things like DLI's and VBI's will "just work". The data I see will be whatever Antic fetches at the time, with whatever state things like the colour register are in at the time of the fetch. I will need to handle fine-scrolling because that's internal to Antic,  but scrolling in a 24-bit RGB world isn't as bad as scrolling in a sub-byte-per-pixel world. I'll be translating the 1/2/4 bits/pixel into 24-bit RGB per pixel for the frame-buffer code anyway, which makes everything just a N-byte-offset.

 

[reifsnyderb]

/HALT isn't available on the XL PBI, unfortunately.  

[+Spaced Cowboy]

I don't *actually* need it, it's just a convenient marker that's all. I can work it out from reads/writes to/from $560,1 or $D402,3 and work it out from first principles

 

Basically, if Antic does something externally to figure out what it's task is, I can monitor for that and track it internally.

[+MrFish]

3 hours ago, MrFish said:

Just so I understand... in short, it's the following...

 

1. Memory (8 MB)

2. Video/Audio Out (HDMI)

3. Ethernet (100 Mbit)

 

and in the future...

4. Ethernet communication with PC for soft peripherals/services

5. Ethernet communication with a hardware box that will have cards for upgrades/services

 

3 hours ago, MrFish said:

Ethernet connecting to something like AspeQt/RespeQt would be useful.

 

16 minutes ago, Spaced Cowboy said:

If what you meant was "I, MrFish, could write something to make AspeQT/RespeQT work with this and it would be awesome", then I'd have to say "I agree, that's an awesome idea" 😀

 

Or if it's "The AspeQT/RespeQT people could do something awesome with this", again I'd have to agree I'm just not committing to doing it myself.

 

I think we're going off in the wrong direction here. You've already said that Ethernet communication with the PC for soft peripherals/services was planned. So, I was merely suggesting that connecting to "something like" AspeQt/RespeQt (not necessarily the application AspeQt/RespeQt itself -- although it may be feasible) would perform a useful function for the interface. You also already mentioned incorporating Fuji-Net, which performs similar functions (disk and printer emulation, etc.); so, I'm basically echoing those sentiments, with specific regards to the functions that RespeQt/AspeQt and Fuji-Net have in common.

 

[+Spaced Cowboy]

Gotcha. I'm just leery of biting off more than I can chew on in one go - this is already ambitious and last time around it suffered a bit from feature-creep, so I'm determined to just (hah, just!) do what needs to be done to make it work before thinking about moving the goalposts. At all. 

 

For the record, Fujinet support is also something that "could be done" (and honestly probably will get done, because why wouldn't you if you have ethernet?) but only once the specific project-goals are accomplished. My mantra this time around is going to be "Stay on target"

 

[+Spaced Cowboy]

2 hours ago, reifsnyderb said:

If there are any device drivers, you could have them in a ROM and have them automatically installed as per the 1090 and PBI specifications.  Using too much of $D1xx will break compatibility with other cards.  (i.e.  The 80 column board.)  Realistically, you have $D100-$D1AF. 

That's more restrictive than I thought, but still probably fine. The bare minimum needed for a memory aperture is 

$+0000 [4]: Base address in PSRAM for start of memory aperture
$+0004 [1]: Page address in host-memory for start of memory aperture
$+0005 [1]: Number of pages to map

For a total of 6 bytes per memory-aperture descriptor. If I wanted to implement hardware sprites and provide blitting of them over the top of the actual display, each would have to be something like:

$+0000 [4]: Base address in PSRAM for start of memory aperture
$+0004 [1]: Page address in host-memory for start of memory aperture
$+0005 [1]: Number of pages to map
$+0006 [1]: 'stride', or pages per horizontal line

For a total of 7 bytes per descriptor. Blitting is specifically a non-goal (at least initially) currently though. For the record, though, the idea would be to make a 'blit' be an operation with one descriptor as source, one as destination, and arguments supplied per-blit for {blending-operation, x, y, w, h}. Using this structure, the descriptor would fit into 8 bytes with one left over for future expansion. So I could keep my 16 apertures from $D100 to $D17F...

 

I'm thinking that a command descriptor would be useful at some point as well - not just for blitting. So maybe 16 bytes from $D180 to $D190, with any operation happening as soon as $D180 was written to (so, set up command-specific data first, then write to command word for $D180,1). 

 

If push comes to shove, the entire thing could be controlled by a single command descriptor - this is how the AES/VDI works on the ST for example - reducing the footprint down to (say) 16 bytes, but I think it's useful to have memory-mapped records for the memory descriptors, it would make changing them much simpler.

2 hours ago, reifsnyderb said:

Below is also a working schematic of the 320k memory module for the 1090.  I am including it as it may help with details such as enabling the data bus and timing.  I've added the 1090 tech spec document as well.

That's interesting, because your timings don't quite match up with the diagram I've been using to date (below). A period of 558ns seems to match up with a clock rate of 1.79MHz, so I'd never actually doubted it. If the address is valid after only 125ns though, it makes life a lot easier for getting MPD/EXSEL asserted in time. 40-45ns is kind of tough (maybe 3 clocks to action things) once you take into account 6-10ns of level-translation delay in both directions, and the worst-case jitter in clock-domain crossing.

 

The timing diagram I have is from the Earl Rice's "The parallel bus revealed" part 2 article in Antic, Feb '85.

 

There's also (as you mention) a few other "holes" in the memory map. I can assert /MPD - and I don't *think* the entire space is even used - the last entry point is at $DED1 (so maybe $DFxx are free ?) according to here - If so, I could assert /MPD only for accesses in  region. I'm also not sure what happens if I assert /EXSEL for anywhere in $D500 -> $D7FF. It might let me supply the data-bus, it might not (whether or not it's *supposed* to work or not )

 

[reifsnyderb]

8 hours ago, Spaced Cowboy said:

That's interesting, because your timings don't quite match up with the diagram I've been using to date (below). A period of 558ns seems to match up with a clock rate of 1.79MHz, so I'd never actually doubted it. If the address is valid after only 125ns though, it makes life a lot easier for getting MPD/EXSEL asserted in time. 40-45ns is kind of tough (maybe 3 clocks to action things) once you take into account 6-10ns of level-translation delay in both directions, and the worst-case jitter in clock-domain crossing.

 

The timing diagram I have is from the Earl Rice's "The parallel bus revealed" part 2 article in Antic, Feb '85.

I just double-checked and my timing numbers are wrong.  Thanks for catching that.  I'll re-compute them and update the document.  I computed them from the datasheet but used the wrong cycle time.

 

The timing diagram from Earl Rice's article is probably correct.  I need to double check.  I have confirmed there is a problem with a documented description of how /EXTENB works and I think it's in his articles.  (I even got bad boards made based upon the wrong explanation of /EXTENB.)

 

I got around a lot of timing issues by using the fast chips such as 74F04 and using the shortened Phi2 generated from the 74LS123.

 

 

8 hours ago, Spaced Cowboy said:

There's also (as you mention) a few other "holes" in the memory map. I can assert /MPD - and I don't *think* the entire space is even used - the last entry point is at $DED1 (so maybe $DFxx are free ?) according to here - If so, I could assert /MPD only for accesses in  region. I'm also not sure what happens if I assert /EXSEL for anywhere in $D500 -> $D7FF. It might let me supply the data-bus, it might not (whether or not it's *supposed* to work or not )

 

There might be a little space at the end of the math pack region.  But I have to question how many bytes the FP base 10 logarithm takes up.  It may be more than one byte as many entries are.  Asserting /EXTSEL will only shut down the internal RAM and nothing else. 

 

(I think you meant $D600 to $D7FF.)  Page 15 of the 1984 document covers the address reservations of $D600 - $D7FF.  I've also uploaded a document that is focused on the use of the memory from $D600-$D7FF.  That all being said, I don't know if any device ever used the region from $D600-$D7FF.  A quick check of the schematics and documentation shows the possibility of the serial/parallel card using the $D600-$D7FF region but the serial/parallel card documentation doesn't support that possibility at all.  None of the other cards appear to use $D600-$D7FF, either.  My belief, at this time, is the the $D600-$D7FF region was never used by Atari as per their documentation. 

 

My thought is that if your PBI device is active (selected in $D1FF) that it could use this region from $D600-$D7FF without any conflicts.

 

 

 

PARALLEL_DEVICE_RAM.pdf

[reifsnyderb]

10 hours ago, Spaced Cowboy said:

That's interesting, because your timings don't quite match up with the diagram I've been using to date (below). A period of 558ns seems to match up with a clock rate of 1.79MHz, so I'd never actually doubted it. If the address is valid after only 125ns though, it makes life a lot easier for getting MPD/EXSEL asserted in time. 40-45ns is kind of tough (maybe 3 clocks to action things) once you take into account 6-10ns of level-translation delay in both directions, and the worst-case jitter in clock-domain crossing.

 

The timing diagram I have is from the Earl Rice's "The parallel bus revealed" part 2 article in Antic, Feb '85.

I re-computed the timing as is below.  I am not sure as to why the numbers differ.  It could be the CPU datasheet he went off of had different numbers.  Also, his timing numbers should be shifted because his chart is for external timing.  Externally, phi2 is shifted by roughly 20ns or so due to the 74LS08 that buffers it on the system board.

 

My inclination is to take the worst of the worst case numbers and design around them.

 

Timing:

 

 

Most timing information on data sheets is accompanied by a timing diagram with variables that have to be cross-referenced in a table to determine the actual timing of each event. As the Atari runs at 1.77 or 1.79 MHz, I decided to put this information in tabular format in chronological order. (PAL systems run at 1.77 MHz and NTSC systems run at 1.79 MHz.) Times are in nanoseconds, the rise/fall time of Phi2 is not shown, and worst-case numbers are used.

 

 

Event: PAL/1.77 MHz NTSC/1.79 MHz

 

Phi2 is low (Start of clock cycle)                0  0

Address is set                                      159  157

R/W is set                                           159   157

Phi2 is high                                         283   279

Data is set (CPU Write)                        396    391

Data setup time for read (CPU Read)    509     503

Phi2 is low                                          565    558

Read data hold time                             576    569

Write data hold time                            632    624

 

Note: Data is computed using the SY6500 datasheet from Synertek.

 

 

You will need to keep in mind propagation delay times of every component in your PBI device to make sure addresses are handled and data is processed and/or ready at the correct time. In addition, Phi2 is buffered and delayed by the 74LS08 on the system board. If a 1090 Expansion is used, an additional delay is created by the transceiver propagation time.

 

[reifsnyderb]

I thought I saw that something used $D600 for RAM and kept looking.  I just found a reference to $D600-$D6FF being used by a PBI device.  As per the Altirra Hardware Reference Manual, page 285, the CSS Black Box used it for RAM.  Given that ICD and CSS didn't follow Atari's PBI specifications, I wouldn't be too worried about it.  Like I said earlier, I think it's safe to use.

[Mathy]

Hello guys

 

2 hours ago, reifsnyderb said:

I thought I saw that something used $D600 for RAM and kept looking.  I just found a reference to $D600-$D6FF being used by a PBI device.  As per the Altirra Hardware Reference Manual, page 285, the CSS Black Box used it for RAM.  Given that ICD and CSS didn't follow Atari's PBI specifications, I wouldn't be too worried about it.  Like I said earlier, I think it's safe to use.

 

VBXE often uses $D6xx, but can also be set to $D7xx.

 

@guus.assmann as well as Matthias Belitz have told me, the BlackBox can be made to share the bus with the addition of a piece of hardware that costs only 50 cents.  Bob Puff confirmed that this is true.  Neither one told me which hardware part that is though.  You might not know Matthias, but Guus developed (among other things) the hardware for the Turbo Freezer and the MegaSpeedy.  I guess we all know Bob and his products.

 

Sincerely

 

Mathy

 

 

 

[+Stephen]

Also, while less common, the Covox audio mod can also use D600 and D280

[+Spaced Cowboy]

Ok, thanks for the updates, folks  If VBXE uses $D6xx by default, then I guess I could go for $D7xx by default, if I need the space. I'd prefer to stay within the $D1xx area though until it's necessary to go outside it.

 

Those figures for the bus timings are still more encouraging than I was was thinking. I have an old HP 16702B here, I might try and put it onto a 130XE and see what I'm actually seeing, rather than the theory. The resolution of the HP LA is ~2.5ns I think, so I ought to be able to get some reasonable timings. The nice thing about the HP is that I can sample the address bus, the data bus, and a few other signals at the same time at that resolution...

 

[+Spaced Cowboy]

So it took me most of the day to get this thing set up (the network subnet has changed since I last used it, it's been *that* long), and one of the sampling boards is now, er ... spare-parts. Turns out I broke off a pin last time I used it - and then I had to remember how to use it...

But as I type, it's saving about 600MB of ASCII (!) data (across the network, it's internal hard disk isn't large enough) over to the server in the garage. I set it up to monitor A[15:0], D[7:0], CLK, R/W, /MPD, /RST, /REF, /CCTL, /HALT, and /IRQ. 

 

I guess this beast isn't *quite* as old as the 130XE (probably made around 1998) but it still feels like one ancient machine inspecting another

 

addenda: 600MB turned out to be a woeful underestimate...

 

Quote

@xanadu:/raid/tmp$ ls -l

total 2337064

-rw-rw-rw- 1 16700 16700 2385847569 Oct  2 22:04 xe-sample

-rw-rw-r-- 1 16700 16700    7296670 Oct  2 20:18 xe-test

 

I'm not sure I need *quite* that much data

[+Spaced Cowboy]

So here's some interesting data... I wrote a little utility to convert between the DOUT format from the logic analyzer and GtkWave's VCD format. The attached ZIP file is the result of that conversion. You ought to be able to (if you want ) download/install GtkWave and point it at this file to see the data for yourself and browse around. It's not the entire dataset, just a small sample. The machine wasn't doing anything particularly interesting (sitting at the READY prompt) so I doubt there's too much more than what you have here, in the full dataset.

 

This is data sampled (as mentioned, and pictured above) from my vintage 130XE, which is unmodified in any way. Original chips, no buffer enhancements, not even a video upgrade. This is the original, warts and all.

 

Here's a trace, chosen at random, where you can see CLK falling at 121200ns into the capture, and the various traces listed down the side:

 

 

The red line is locked to the address becoming stable. It's zoomed out because I wanted to show a whole clock cycle to demonstrate that stability, but GtkWave snaps to the event on the line the cursor is on, so I know it corresponds to that line (the cursor was over the address when I took this snapshot). The cursor is at 35500ps from the falling edge clock, so the address stabilised 35.5ns into the clock-cycle.

 

Similarly, the data bus is stable at 111500ps, or 111.5ns into the cycle. This is on a CPU-generated (/halt=1) read cycle (r/w=1). On a write cycle we get:

 

 

And in this case, the address is stable 45ns into the clock cycle, and the data-bus is stable 296ns into the cycle. The R/W signal itself is valid and stable a couple of ns later than the address (47ns). When ANTIC is accessing the bus (the clock after /HALT goes low), I see:

 

 

And here we have an address 25.5ns after the clock's falling edge, and data stable at 87.5ns after that same falling edge.

 

Now I'm not saying that the official figures are wrong in any way, but I am saying that maybe there's a lot more leeway than they might at first imply. All the data above is sampled using a CART+ECI board plugged into the back of the 130XE, so if there's any buffering going on, the data will be subject to those delays, built into the timings above...

 

Anyway, interesting. If this is generally true, it means I really don't need the ultra-fast level-converters I was looking for in order to minimise the round-trip delay between Address-becoming-stable and /MPD-must-be-asserted. I can't say I'd be comfortable relying on 35ns delay for address-becomes-stable, but there's a huge gaping chasm between 35ns and 177ns...

 

I should also mention that the sampling was taken at 400MHz, so the resolution of each point is to 2.5ns.

 

xe-test.vcd.zip

[ijor]

14 hours ago, Spaced Cowboy said:

Now I'm not saying that the official figures are wrong in any way, but I am saying that maybe there's a lot more leeway than they might at first imply.

You posted several measurements. Exactly which "official" figures are you claiming that are wrong (or that there might be more leeway than it seems)? And from which documents are you getting the "official" data? Some specifications, such as those for SALLY, were never published.

 

 

Edited October 4, 2022 by ijor

[+Spaced Cowboy]

I'm somewhat abusing "official" here. I meant the timing diagrams that have been published previously (like above) and the calculations from @reifsnyderb above. 

 

The address-valid timing is 177ns from the falling clock edge (for example) in the ANTIC figures from Earl Rice. I'm seeing a *lot* less than that in practice. It may be that the spec is über conservative, or it may be that the 800XL is far worse than the 130XE, or it may be a legacy from even earlier days with arcade machines, or it may be some combination of all of these.

 

It's also possible there's circumstances I'm not seeing in the measurements that pop up now and then, but the bus-cycle of a 6502 is fairly simple overall, I'd be surprised if there was *that* much variation possible.

 

[ijor]

6 hours ago, Spaced Cowboy said:

It may be that the spec is über conservative,

 

Specs are always conservative (so to speak) by definition. A published specification means that every single chip sold by official channels is guaranteed to meet the timing in the worst voltage and temperature conditions allowed.

 

Some chips are faster than others, even within the same speed grade, and you are rarely so unlucky to have the worst one. Plus you normally don't run the system on the worst voltage and temperature condition. So it is normal in practice to get a much better timing than published. Now, you can decide to design for the worst case according to the specs, or for the common, average case and don't care if it would fail in a few cases.

 

But again, there are no published specs for SALLY. It should be, approximately, the same as a standard NMOS 6502. But we don't know which speed grade (we had a long thread about this some years ago). And certainly there are no available specs for the extra logic in SALLY that would affect the timing for most signals.

[reifsnyderb]

I thought I read a better document on how to implement a parallel device.  Here it is:

 

sw_implementation_of_parallel_devs-drvrs.pdf

[+Spaced Cowboy]

2 hours ago, reifsnyderb said:

I thought I read a better document on how to implement a parallel device.  Here it is:

That's *really* useful - thanks a bunch