To infinity and beyond... (new hardware)

[_The Doctor__]

I'd try to stick with assembly, and what about H's for major/master F for minor/slave work? The differing cards with h/f can co-exist ?possibly?

[+Spaced Cowboy]

The chips can certainly interoperate - they can both run at 3.3v and the 'F' can tolerate 5v inputs (it still outputs at 3.3v, but that's sufficient for a logical 'high' even on a 5v circuit). The annoying part is that it's the one that's connected to the 5v supply that would benefit the most from the additional speed - this is for two reasons:

 

1) The 'H' part has 128k of tightly-coupled data RAM - only the CPU has access to it, so nothing can impede access, eg: a DMA event or what have you). That would be really useful for a 64k map of which routine to call within the interrupt that is triggered by the clock. It's going to be far faster to look up a byte-value in an array of 64k, than search through a list of memory apertures to figure out what we ought to be doing.

 

At startup, all 65536 entries are 0xff (which means we don't do anything). If the value is

   0..0xf     : means one of the memory apertures is active, so calculate the address within SDRAM and return/write the data
   0x10..0x1f : means it's associated with the video system, (DL lookup, charset fetch, data fetch,...)
   etc.

The 'F' part only has 16k of tightly-coupled RAM so either I reduce the resolution of the map, or I use SDRAM (which is much slower - random access to SDRAM is ~50ns, random access to the DTCM is 5ns)

 

2) Once I have one of them in there, there are benefits on speed for interconnect between them if they're both 'H' parts. The SPI interface (which is going to be my primary connection) is 150 MBit/sec on the 'H' part, whereas it's "only" 50 MBit/sec on the 'F' part. If we're going to get to the point where people can copy sprite data from directly-accessible SDRAM to the frame-buffer SDRAM, we want that to be as fast as possible.

 

I'd been trying to think of a good way to split up the data into the three 50 Mbit/sec SPI pipes I had set aside when designing for the 'F' parts, given that it's not a dedicated channel (it has to carry memory-to-memory copy-ops, ethernet data, USB data, SD-card data etc.). With the 'H' part, that problem might go away. I could still try doing the packetised data-format copies if it came to it.

 

[aside]

What I was thinking of was

• Send packet-type over SPI #1
• Send packet-length high-byte ('N/256') over SPI #2
• Send packet-length low-byte ('N%256') over SPI #3
• Alternatively read up to N bytes from *all of* SPI #1, #2, and #3 using DMA

Which would effectively give me 150 MBit/sec. I'd then split the data into different circular buffers on the destination side based on the packet-type and call a handler for that data-type.

 

It's a lot easier, however, to say SPI #1 is video data, SPI #2 is ethernet data, SPI #3 is everything else. All of them get 150 MBit/sec. If I did combine the faster pipes in the same way as above, we'd be approaching 450 MBit/sec...

[/aside]

 

I think I am going to go with 2x 'H' variants, I think the balance of pros and cons is in favour of that configuration. Now I have to figure out if it's going to be BGA or QFP packaging, which'll be based on availability. Then I have to create the parts in Eagle, then integrate into the existing schematic design.

 

 

On a totally different note, I made a test-run for the VHDCI connector part, building what I hoped would be an interface I could plug into the ECI port on one side, and map the pins to a VHDCI connector on the other. The land-pattern (the pads on the PCB) didn't line up with a real VHDCI connector on one side. It turns out that the part I'd ordered from Mouser is now discontinued, and they'd been linking to the datasheet for a different part with a very similar name. Which is annoying. They've since changed it, but the "corrected" data-sheet doesn't even have the dimensional drawings you'd need to create a part in a CAD system...

 

I ordered the new part to see if that's a better fit. I was a little concerned by the fact that Mouser didn't mention anything about it being discontinued until stock was exhausted, so I tried a search on Amphenol's site, and got nothing back. I'm now thinking I have to find an alternative to the VHDCI connector as well, because according to octopart, there's only 688 of them available from Mouser, and that's it. It looks as though the world is moving away from bulk parallel cables to high-speed serial, and what I thought was an ideal solution is no longer being manufactured. I guess I'm glad I found that out now.

 

[update]

After a bit more googling and searching, it seems there's still quite a vibrant VHDCI market out there, so I'll probably stick with the connector style, but I think I'll move to a more-common instance of it. Again, it adds expense (this new style are available at $7.26 each rather than the $4-ish each of the previous style) but there's thousands of them out there for sale, which is much more reassuring. It means I'll have to create a new footprint for the part, but hey...

 

Simon.

[+Spaced Cowboy]

Quick update on the design

 

I spent the last few days upgrading the processors in both the schematics and layout, I started the autorouter this morning at ~11:30, it's now 9:30pm and we're at:

... I didn't actually expect to see the 100% figure - it only appeared at the 'Optimise3' stage of the route operation.

Anyway, what's changed:

• Both CPUs are now 'STM32H7' types
• I found level translators for the interface-CPU (called 'XIO' in the schematic) that can sink/source sufficient current to drive over even a fairly long cable. I'm hoping the VHDCI cables I'm planning on using will be fine.
• We now have one USB complex available from both CPUs, for two in total
• The PSRAM has been exchanged for SDRAM on the XIO chip, so there's actually 64MB of RAM on board, 32MB for graphics use, and 32MB directly mappable to the host 8-bit.
• There's ESD protection on all the vulnerable ports (HDMI, USB, Serial) - either built-in to the driver chips or inserted between said driver chips and the ports. That way, you don't zap the expensive board when you plug in a cable.
• The main voltage regulators have immense copper pads and large numbers of vias for thermal reasons. Just in case
• There are 3 SPI ports between the two CPUs. One runs at 133 MHz (the fastest supported for both read and write), the other two run at 100 MHz. That's a huge amount of bandwidth between the two CPUs, and it'll all be DMA driven, so won't impact the CPU much even at full blast.
• We now have a reset switch and a supervisory circuit to monitor the voltage levels.
• We're using a more-available VHDCI connector
• The plug-in I2C and SPI extensions for things I might want to do inside the case have PWR/GND pins now as well as signal lines...
• As well as the above, I've also incorporated all the first review comments into the design. Second review will be next week sometime I think.

 

There's still a few things I want to do - example: I'd mentioned the audio-level-translation thing to my boss, and he suggested using an op-amp in an amplifier configuration to get better resolution from the ADCs, things like that. I also need to clean up the board labelling a *lot*, but that's generally the last thing I do, because the routing/vias can change things so much.

[_The Doctor__]

So glad you chose to mess with this stuff again/more. It's shaping up nicely

[foft]

How did you esd protection to the ports?

Edited July 7, 2018 by foft

[+Spaced Cowboy]

How did you esd protection to the ports?

 

 

The serial ports I used the 'E' variant of the MAX3232, which have ESD built in. The USB ports have an RCLAMP0502N - they're the tiny parts just above the [GND] and [*_USB_P] pins on the USB sockets. Easiest to see on the right hand side...

 

 

 

The ethernet port isn't so susceptible because of the magnetics built-in, but the HDMI port is, so here I used an MG2040 to protect the 4 differential lines, as well as I2C, hot-plug detect, and the CEC signal. Again, it's pretty small, but you can see it just above the HDMI traces coming out of the HDMI socket:

 

 

Cheers

Simon

[+Spaced Cowboy]

Unexpected Setback

 

I sent in a test-design to seeed a couple of days ago, actually just to gauge the price for the assembly of all the parts on the board. At quantity-5 it comes to ~$2k (ouch!) but that's because of the low volume. The big deal, though, was that they rejected the board for assembly anyway, because they couldn't locate any of the STMH7 chips in mainland China - I wasn't aware that their source had to be China, but I guess it makes sense from a delivery-costs perspective.

 

So, now I have a design that I can't manufacture

 

There's a few ways around it that I can think of, but none of them are especially attractive...

 

• The 176-pin version of the chip seems to be available in China, but I have to figure out how I could reconfigure the board. I'm using pretty much all the pins (maybe 20 not used) of 2x 208-pin processors.
• I could go back to the STM32F7, but it has drawbacks in terms of internal RAM buffer for quickly managing the memory-aperture maps. It's also not clear that the one I would drop-in to replace the 'H' model is available in China either.
• I could try (another!) re-design back to more of the original idea, where I put a CPU local to the 8-bit host, handle the decoding logic (including ADC) locally, serialise/de-serialise the data (thus reducing the pin-count dedicated to the 8-bit bus) and try to get it to work over CAT6 again. Part of the reason for the larger chips is the parallel bus that interfaces to the host. This is a major re-design though.

I've sent an email to Seeed, to try and get some clarity on where they source from. I guess that's going to be the driver of what solution I eventually come up with. It's just kind of annoying to get the news at this late stage of the project, when I'm about a week away from pressing the trigger, that it can't be done in this form...

 

Simon

[Dropcheck]

I'd check other board manufactures/assemblers just as a check on SEEED. They are not the only game in town surely.

 

Also another thought as to the expense ratio per board. Perhaps it might be best to do a modular approach. I doubt the demand would be higher than a few hundred boards. At that number you are still looking at a sizeable cost for the user for a one size fits all board. It's nice to have it all, if you can afford it, but not many will be able to.

Edited July 12, 2018 by Dropcheck

[+Spaced Cowboy]

The reason I'm keen on Seeed is that I have a $500 voucher which expires in August

 

As for the pricing, it does come down a lot as you scale up. It wouldn't be much more (ignoring component costs) to get 10 boards done, rather than 5. The Q5 price for the PCB is $95, the Q100 price is $9.

 

I have thought along the same lines though - I could simplify it a lot if I got rid of the PIO part, and made that a plug-in board (it does have slots after all [grin]) but that means you lose ethernet, hdmi, and usb. It also means there's no "as standard" high-res video, which would act as a barrier to people actually using it. It may come down to that after all, though. If I can't get the parts, I may be forced to compromise.

 

I've been looking at using an FPGA with SERDES to reduce pin-count, and get a low-latency connection (maybe 1 Gbit/sec) link between the host-board and the box, but I think that's a level of complexity I don't really want to tackle. It would mean I could go back to the RJ45 as a connector, but writing a whole transmission protocol ( I was kind of surprised there wasn't anything out there already that you don't have to pay for) with link-training and bit-slipping before getting data-lock is a *lot* of work. So, I'm going to ask one of the FPGA guys here today about it, but my gut feeling is that that's out.

 

Which, unless I can figure out a way to get the built-in SPI up to an acceptable speed, brings me back to a high-pin-count parallel interface, which means either more chips or less functionality.

[Dropcheck]

As for the pricing, it does come down a lot as you scale up. It wouldn't be much more (ignoring component costs) to get 10 boards done, rather than 5. The Q5 price for the PCB is $95, the Q100 price is $9.

I think you are side stepping the comparison. The price you quoted earlier was for five completely assembled boards, parts and all. Even if you scale up to a couple of hundred completely assembled boards, you're still talking around a $100 or more per board. The cost might be a little less if you do most or all of the assembly yourself. Assuming of course that you had the tools and skills to do it yourself. But then you would most likely be shorting yourself on the labor costs. Candle can tell you of his 'fun' in producing the early VBXE and U1mb boards himself back in the day. They were much smaller and simpler than your design.

Not much you can do with a bare pcb except look at it and admire the design. I have to say I do find your design somewhat sexy though.

 

It's okay to dream. I don't want to smother that. I'm just saying you have to be realistic too, particularly if you are creating something for someone else. I have no doubt that some on this site would happily pay the cost for the Lamborghini version, but most would balk at the cost of the Lincoln Continental version. Most of us can barely afford the Chevy version.

 

Feature creep is deadly.

 

At the risk of sounding preachy.....If you truly want the ability to add features to the Atari by simply adding a feature board to the slot, then design the base board for that. Leave the plug in boards to handle the features themselves. You can design both, but in a modular way. Let the user decide what feature board they want and can afford.

 

Anyway, my three cents worth. (Inflation....)

[+Spaced Cowboy]

At the risk of sounding preachy.....If you truly want the ability to add features to the Atari by simply adding a feature board to the slot, then design the base board for that. Leave the plug in boards to handle the features themselves. You can design both, but in a modular way. Let the user decide what feature board they want and can afford.

 

So I thought about that for a bit, and in the end I decided Dropcheck was right. I was concerned that there wouldn't be any take-up of add-on video/ethernet/what-have-you boards, but considering:

• the cost,
• the time deadline for my Seeed voucher to time out (hey, it's $500!)
• and the risk-factor (I don't yet know if the video idea will work, it doesn't make much sense to make everyone who gets one pay for it, if it doesn't - I think it'll work, it seems like it should, but as far as I know, no-one has actually done it before...),

... I decided to cut my losses ...

 

So, the new design is simpler, has more restrictions (due to less pins and more space constraints) but it ought to be cheaper and easier to produce. Here's the prior-to-routing (which is happening as I type ) layout:

 

 

 

Things of note (in no particular order)

• All the ports along the bottom stick out the back of the case. The box will still be 17x17cm so that cards can be larger if they choose, but the motherboard is only 17x10cm.
• We keep the SD-card slot, although it's moved to about half-way up the side of the box now.
• We keep the 32MB of SDRAM, with 16-bit access
• We're using the original chip (an STM32F746BGT6) rather than the newer 'H' variant so that it can be assembled by Seeed.
• We lose the ethernet and the HDMI. Without two chips, I just don't have the pins.
• We lose 2 (of the 7 previous) expansion slots.
• We lose one of the USB complexes. Not a huge deal, you can still plug in a USB hub.
• We keep one serial port with a DB9, the second is now an internal header only (JP1 at the top)
• The slots are now much closer to the back of the case, meaning that the dirt-cheap 10cm by 10cm boards you can have made, can now be expansion cards assuming the appropriate cut-outs.
• The cartridge port is integrated into the back of the case. I'm using this part to provide the cartridge slot. I'm not sure what physical constraints there are on the slot though. Are those stick-out tabs at the side necessary ?
• We gain 2 8-bit ports (USR_A and USR_B) which also have a clock and a misc-data-line each. I recall that the BBC micro's "User" port was pretty popular, so I figured having something that you could easily bread-board with using a ribbon cable might be useful.
• Similarly, each slot has access to the internal UART pins, so can drive them when debugging a card. These take the place of the I2C pins, because we're not using I2C any more.
• The entire board is powered by a 5v supply, but there's no 5v signaling on the board. You do have access still to the 5v rail from the slots, and in fact everything ought to be robust against 5v, but good practice is to make all cards drive 3.3v only.
• Slots have read-only access to all the bus signals. If you need to return a value, do it via the STM32, otherwise we could have one card driving ground while another drives high.
• The host-personality card (the card that interfaces with the host) will have a Coolrunner XPLA3 CPLD on it. This is 5v tolerant, can drive 40mA per pin, and can handle any directionality changes of the signaling under control of the STM32. This means I get level-changing (all outputs are 3.3v), single-load signal buffering on the host side, sufficient drive strength to go via the VHDCI cable, and it's programmable to boot, so if I need to change the directionality of a pin under some circumstance, it's just a bitstream change.

 

So, some fallout from the above is that the replicated cartridge port on the back will be running at 3.3v. I don't think this'll be an issue - 3.3v was chosen so that a driven voltage would work with 5v signaling without problems, and any outputs driven to 5v will be acceptable to the components on the board. I'll still supply 5v to the '5v' rail on the cartridge port as well, in case anyone is sourcing power from it.

 

The only issue I can see is that if a cartridge drives 5v onto the D[0..7] lines (for example), and a card in a slot is only tolerant to 3.3v, it could damage that card. Perhaps I need to isolate the cartridge connector, so that it always drives 3.3v, and then declare 5v logic verboten. Another CPLD could probably manage that, it's just squeezing it in physically that'd be the problem. If I swapped around the VHDCI and the cartridge port, I could probably fit one into that space by the CPU.

 

[update]

And here it is, routed:

 

 

This routes at 6/6 on a 4-layer board, and uses only 0.3mm drills for vias. Contrast that with the previous board. that required a 4/4 space/trace and was really crying out for a 6-layer board. The previous version also needed 0.1mm solder dams (we can now get away with 0.4mm, which is cheaper) and 0.2mm drills. That adds up. At q5, instead of it being $95/board, it's $106 for all the boards, so ~$21/board. At Q100, we're looking at ~$4/board.

 

Simon

[Dropcheck]

• The slots are now much closer to the back of the case, meaning that the dirt-cheap 10cm by 10cm boards you can have made, can now be expansion cards assuming the appropriate cut-outs.
• The cartridge port is integrated into the back of the case. I'm using this part to provide the cartridge slot. I'm not sure what physical constraints there are on the slot though. Are those stick-out tabs at the side necessary ?

The movement of the slots is a good idea I believe. The 10cm x 10cm boards are dirt cheap. If you need more board space you can always sandwiche two boards and stick them in the slot with the most free space around it. Plenty of design options there.

 

Those tabs are the bane of everyone trying to design a cartridge port access. The only cartridge type I know of that needs those tabs is the brown Atari ones. But that covers a large number of game and productivity software. Those tabs pry open the dust trap door on the bottom of the cartridge. Sad to say you will need to account for them in some form or fashion. Either through a 3d print object or by using an original cartridge guide part from a 600XL/800XL.

 

The connector you list is the correct one for RA mounting. There is a vertical version listed on Mouser's site too. For dimension check and planning you can use the cartridge guide from a 600XL/800XL. They are relatively easy to remove as they are not soldered in place of course. I have a broken one(the end anchor tab is broken off) that still can give you the necessary dimensions. I can send it to you if you can't pull one from a 600XL/800XL and don't want to order one from Best Electronics.

 

 

So, some fallout from the above is that the replicated cartridge port on the back will be running at 3.3v. I don't think this'll be an issue - 3.3v was chosen so that a driven voltage would work with 5v signaling without problems, and any outputs driven to 5v will be acceptable to the components on the board. I'll still supply 5v to the '5v' rail on the cartridge port as well, in case anyone is sourcing power from it.

 

The only issue I can see is that if a cartridge drives 5v onto the D[0..7] lines (for example), and a card in a slot is only tolerant to 3.3v, it could damage that card. Perhaps I need to isolate the cartridge connector, so that it always drives 3.3v, and then declare 5v logic verboten. Another CPLD could probably manage that, it's just squeezing it in physically that'd be the problem. If I swapped around the VHDCI and the cartridge port, I could probably fit one into that space by the CPU.

Could you use a simple level shifter? Mytek mentioned a chip in the wifi modem thread that should work to protect the +5v intolerant circuitry of the rest of the board. I forget the part # now. It was TH, but I'm sure there is a SMT version too.

 

Edit:

 

Found it! SN74AHCT125N

Edited July 14, 2018 by Dropcheck

[+Spaced Cowboy]

The movement of the slots is a good idea I believe. The 10cm x 10cm boards are dirt cheap. If you need more board space you can always sandwiche two boards and stick them in the slot with the most free space around it. Plenty of design options there.

That was actually a goal from the start, I had to move the chips towards the back of the board because I couldn't get the simulations of the high-speed lines (HDMI, ethernet) to pass otherwise. Making it easy to produce things that work with the expansion box seems like a no-brainer

 

Those tabs are the bane of everyone trying to design a cartridge port access. The only cartridge type I know of that needs those tabs is the brown Atari ones. But that covers a large number of game and productivity software. Those tabs pry open the dust trap door on the bottom of the cartridge. Sad to say you will need to account for them in some form or fashion. Either through a 3d print object or by using an original cartridge guide part from a 600XL/800XL.

 

The connector you list is the correct one for RA mounting. There is a vertical version listed on Mouser's site too. For dimension check and planning you can use the cartridge guide from a 600XL/800XL. They are relatively easy to remove as they are not soldered in place of course. I have a broken one(the end anchor tab is broken off) that still can give you the necessary dimensions. I can send it to you if you can't pull one from a 600XL/800XL and don't want to order one from Best Electronics.

I don't have an XL to hand but there's an XE sitting here. hopefully it's something I can 3d-print or build after the fact. I'm going to have some sort of a bar extending along the back of the box anyway, for the tabs at the bottom of the slot-covers to fit into and anchor themselves in. Hopefully I can leverage that as a base to work from.

 

Could you use a simple level shifter? Mytek mentioned a chip in the wifi modem thread that should work to protect the +5v intolerant circuitry of the rest of the board. I forget the part # now. It was TH, but I'm sure there is a SMT version too.

 

Edit:

 

Found it! SN74AHCT125N

Level shifter is a good idea - they're cheaper than CPLD's. I was going to completely isolate the cartridge using the CPLD (effectively make it into a big mux) but I think the level-shifter is easier. I do think I need a different level-shifter, though, the data-bus is bi-directional (based on the R/W line) if I'm assuming that more complicated cartridges will be supported and it looks as though the SN74AHCT125N is a high-z-or-output-enabled type of chip. As far as I can tell I need control over the following lines:

 

• D[0..7] : Needs to be bi-directional based on the R/W line. On a *read*, it has to drive the outputs, on a write, it has to pass the outputs through to the cartridge. I think a better chip for this is the SN74LVC8T245PWR with the cartridge configured to be on the 'A' side, and R/W directly driving DIR
• /S4, /S5, /MPD, /EXSEL, /IRQ : These are output-only but could be pulled up to 5v by the cartridge until asserted low, so I'd cover these too. The chip you mention above does say in its data sheet that Vcc can range from -0.5v to 7v, but I see their recommended usage is Vcc=4.5->5.5v, and digikey's summary page lists it as the same (4.5->5.5)... I'd want to be running Vcc at 3.3v and allow the signals to go up to 5v. Given that (a) this is for assembly, so you're charged by different part, and (b) the voltage thing, I might just use two of the SN74LVC8T245PWR's, tying the DIR and OE appropriately. I'd have to use 2 of the SN74AHCT125N's anyway (for 5 signals), so the price difference for the single SN74LVC8T245PWR is pretty small (17 ¢, q1 )

 

[update] I moved some of the parts around to make some space for the level-shifters - the slots are still within the 10cm boundary because the board is only 10cm I ought to mention I'm planning on having the back indent where the slots are by about 1cm, so there's ample space for the card to fit.

 

 

 

 

[update 2] I just realized there's no /IRQ, /MPD, /EXSEL on the cartridge port so I would only need the one SN74AHCT125N ... I'll still probably use the 2 SN74LVC8T245PWR's though, for the VCC uncertainty issue

 

Cheers

Simon

[+Spaced Cowboy]

So I added the level-shifters, and moved the components around again, this time to allow some space either side of the cartridge port so there's some space to put those darn tabs. I routed it out again, and the board now looks like:

 

 

This is without the ground/power planes being indicated, so the traces show up better.

 

I also ran the BOM through Seeed's PCBA quotation system, and they couldn't match up a couple of line-items, but they were just capacitors. I can find alternatives for those easily enough. The costings are significantly better:

 

 

I'd originally budgeted around $150 for Q100 prices including a board, so it looks as though we're now on-target for that, (after simplifying it a lot, courtesy of Dropcheck's point ), given that the box ought to be ~$50 at that quantity.

 

There's going to be other costs, though - the VHDCI cable is ~$25 (from memory) and there'll need to be a slightly more complex host-board as well, which'll add a bit to the price. If a box is needed for that (ie: on a stock XL/XE), there'll be a box-cost for that too.

 

Still, I think this is pretty viable. Now what I'll want to do is make sure I can get the STM chip to respond sufficiently quickly that it's useable as a box interface, and we're in business. I'll spend some time writing some code for the STM, and just implement on a test board first, running it via the logic analyser to figure out timings. Once I have the routine working to that extent, I'll interface it with the XL and assuming that goes well, we're in business.

 

My deadline is August 18th, which is when I have to submit the new board to Seeed to keep my voucher, so there's some time left yet. In the meantime, I plan to send off a small board to OSHpark, which just has the footprints I'm using. I've ordered all the parts I need as single-items from Digikey, and I can do a test-fit.

 

Anyway, I'm happy with the progress, so this is sort of a check-point post. Enjoy

 

Simon

[+Spaced Cowboy]

Question about cartridges

 

I've been running through some scenarios to test the /MPD and /EXSEL activation, and I think the timing may be a bit tight to let the STM handle everything, given the 45ns window to get a valid address and then activate /MPD and/or /EXTSEL. It's probably still (just-about) do-able, but I like to give myself as much wiggle-room as possible during design. There's no problem returning the data over the data-bus (there's ~310ns for that!), but indicating that "there will be data to return" has pretty tight timing. Letting the STM handle the data-transport only also frees it up to do more processing outside the interrupt scope.

 

One possibility is to make the /MPD and /EXTSEL decoding happen within the CPLD/FPGA that's sitting local to the bus (then the only delays are the voltage-conversion ones, there's no interrupt latency, no parsing time, and no execution time for bit manipulation). Basically, do it in hardware, local to the machine.

 

For that to happen, I need to have the memory aperture spans defined within that CPLD and I can do that by using a slightly larger CPLD (looking at a Mach XO2 - I have to do level translation for that chip, but I can make directionality all controllable by the CPLD). All well and good. I just want to check that we're ok with cartridges too...

 

There doesn't seem to be a per-access signal for cartridge data retrieval, it looks as though the cartridge asserts RD4 and/or RD5, presumably by tying them high on cartridge-insertion, and then the computer will assert /S4 or /S5 when the access is within the cartridge range $8000...$9FFF or $A000...$BFFF. There doesn't appear to be anything I have to do on a clock-by-clock basis.

 

So my plan would be: if RD4 or RD5 are ever asserted, switch into "cartridge mode", ignore any set-up memory apertures, and let the cartridge strut its funky stuff. There'll still be some delays due to level-conversion times, but even taking that into account I think we comfortably fit within the budget for read-data-returns (with about 50ns to spare), so even if the cartridge is a bit sloppy, we ought to be ok.

 

Comments ?

[+Spaced Cowboy]

Question about interrupts:

While I'm at it, another question

The expansion box could take over the parallel bus. I could do that, but if there are other peripherals which allow daisy-chaining of the PBI/ECI then it behoves me to play nice. So I was reading up on the interrupt request line, and I'm not sure I'm grokking how it's supposed to work. From: http://atariki.krap.pl/images/2/27/1090.txt

3. The location D1FFH in the CPU memory map is reserved for passing
control information between the CPU and the E.B.P.s. The CPU selects
one of the E.B.P. devices by writing a "1" into the desired bit in
location D1FFH. The device can be deselected by writing a "0" into the
desired bit.

7 6 5 4 3 2 1 0
-----------------------------------------
| D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
-----------------------------------------


Therefore the CPU can then access 8 devices, one at a time. If the
IRQ' line is pulled "low" the CPU can read the status for location
D1FFH and locate the requesting E.B.P.. A "1" in a bit Ix (where x=0
to 7) corresponds to an interrupt in E.B.P. x. If the bit is a "0"
then the device has not caused the interrupt. The E.B.P. must clear
the interrupt flag when the interrupt is being serviced.

7 6 5 4 3 2 1 0
-----------------------------------------
| I7 | I6 | I5 | I4 | I3 | I2 | I1 | I0 |
-----------------------------------------

Ok, how does this work ?

 

I get the selection stuff - the expansion box will monitor writes to $D1FF to make sure its only active when the bit in $d1ff is set to the same value as the dip-switches on-board unless memory-aperture maps are in use. No problems there, but for interrupts, does it work like:

 

• Expansion box asserts /IRQ on the bus
• OS, in turn, writes 0x01, 0x02, 0x04, 0x80, 0x10, 0x20, 0x40, 0x80 to $d1ff
• Peripheral at that id notes that it is now the active one
• For each of those writes, the OS then reads $d1ff, and if the value is non-zero, we have an interrupt.

Which means that if you set your box to be id 7, then it takes 8 iterations to service each interrupt ? Crazy! They had the whole page to reserve bytes within...

 

Or are the peripherals supposed to only drive their own bit-line on a read-access to $d1ff ? There has to be some way of preventing two peripherals trying to drive (for example) 0x01 and 0x02 simultaneously over the same data bus...

 

Simon.

[+mytek]

It's all Chinese to me . Haven't delved into the PBI all that much myself, but I bet there are several other AA members that might be able to shine some light on that.

[Osgeld]

check with smart-prototyping, I have used them a bunch and are often a little bit less than seeeeeeeeeeeeeeeeeeeeeeeed

[flashjazzcat]

Check this out:

 

http://www.oocities.org/dr_seppel/pbi2_eng.htm

 

Also check the OS source code.

[Dropcheck]

A collection of documentation on the PBI and related hardware is here.

[+Spaced Cowboy]

A collection of documentation on the PBI and related hardware is here.

 

Useful! Thanks

 

Check this out:

 

http://www.oocities.org/dr_seppel/pbi2_eng.htm

 

Also check the OS source code.

 

 

Thanks, that makes it clear - its the latter ("peripherals only drive their own bit-line), which ought to be relatively simple to do.

[+Spaced Cowboy]

Quandary

So, I've been playing with a STM Discovery board, interfaced with the little pcb that exposes the bus signals on 0.1" headers, and I can confirm that post #90 above is definitely on the cards.

I've also been reading up on the 6502's bus timings, and I'm a bit concerned about the cartridge placement in the expansion box. On a read operation the 6502 latches the incoming data on the falling edge of ∅2. The CPU data-sheet says that the read-data must be available on the bus by the indicated time, however, and in our case (it's dependent on the clock frequency), that's 486 ns after the previous falling edge of ∅2. This gives me a headache...

If I'm the designer of a cartridge, and I get a read operation coming in, the way I'd do it is return the data ASAP, probably only limited by the hardware response time, ie: (eep)rom read; however, the spec says everything is cool as long as the timing is met, which means people could have played fast and loose with that, there could be internal delays, or whatever - and as long as the data gets onto the bus by 486ns, they're golden.

Now consider the return data path for a cartridge that's talking via a level-changing CPLD, let's say I run the CPLD at 100 MHz clock....

[cartridge asserts data on line]
  [CPLD counter reaches 486ns after falling clock edge]
  [Level translator from cartridges native 5v to 3.3v] [7ns]
  [CPLD latches bus data on input pins and transfers to host-side output pins] [20 or 30ns if using synchronizer flip-flops]
  [Level translator from 3.3v to 5v] [7ns]
  [Data reaches host at 520ns or 530ns]

Now this is still comfortably before the next trailing edge of ∅2 (at 586ns) but I'm sure there's a reason why read data has to be asserted on the bus at 486ns and not 520ns - note that the write-timing is different again at 422ns, these all seem to be very specific numbers. The 6502 squeezes bus cycles into a single clock (unlike most CPUs of the time which read data 1-clock-delayed) so I don't know what's going on internally, but I'm sure it's very clever. Clever logic is often fragile to changes in circumstance...

So, I have to make a call - there are two options as I see it:

• ​I could leave things as-is. I wouldn't be able to guarantee that all cartridges would work though - I suspect most would, and I could make the CPLD propagate data as it detects changes, rather than waiting for the 486ns, which would alleviate the problem in the majority of cases. This is probably a 99% option (I really don't think there's many cartridges out there that need the full time allocated to return their data, I suspect the overwhelming majority will have some decoding delay, and 180ns or so of eeprom delay, and maybe some bus-logic delay, which still gives plenty of time). There's bound to be corner-cases though where it already "just" met timing.

• I could move the cartridge port onto the "live" 5v side of the bus, and electrically it's no different than its original circumstance. On the 800XL it doesn't matter, there's a cartridge port anyway. On the XE, I can put a cartridge interface on the PCB that attaches to the ECI, again no problem. The only downside of this is that small cases (mini-ITX or what-have-you) have to have their cartridge slot wired into the machine case, rather than exposed via the expansion box case - in this case I'd provide a pin-header for the cartridge and a short ribbon cable to a pcb with a cartridge slot that could be screwed to wherever the current cartridge slot hole is on the case. The upside is that it ought to be 100% compatible, however there's one more wrinkle with this in that some people may have positioned their cartridge slot hole directly over the existing ECI port on the 1088XEL. In that case, I'm not sure there's a great solution - it might be possible to mount a PCB onto the provided pin-header such that the secondary cartridge slot is in the same X,Y location as the 1088XEL one, but obviously changed in Z - that's probably the best I could do. To be honest though, if someone had cut a hole in the top of their case, that hole wasn't going to be pretty anyway once the ECI port had been taken by the expansion box host-card...

I'm personally leaning towards the second (IMHO safer) option - it also allows me to ditch the (expensive, the cable is ~$29 and each connector is ~$13 for a total of $55) VHDCI interconnect because the cartridge is the driving force for those bus-signals to be exposed in parallel, I control the timing on everything else. Since I'm doing programmable logic anyway with the CPLD, I could serialise the parallel data over (say) a USB-C connector or DVI connector instead (2 LVDS data lines + LVDS clock in both directions gives me ~1.6Gbit/s bandwidth full duplex). That might mean going to a small FPGA to get the bandwidth, but I'd still stay with QFP as the packaging to reduce cost, and I could probably ditch one of the STM32's as a by-product.

I'd like to canvas opinion though - I don't personally like 99% "solutions", but I'm not planning to be the only person using this - at least I hope not So I'm interested in what people think...

Cheers
Simon

 

[by the way, I'm aware the images have stopped showing up - the machine that serves them is hosted at my house, and it's switched off for its own protection while we have power-wall's installed. Hopefully today and tomorrow will be the last time I ever get a power-failure at home :]

[+Spaced Cowboy]

Well, in the absence of any external opinion, I'm gonna go with ... hedging my bets.

 

I'll put down a full pin-out of the cartridge port on the host-side board, to which something similar to DropCheck's board could be attached. I don't know if I'll put down an actual cartridge port, probably just pin-headers, but it'll work the same way as a cartridge port, all the signals will be there. This will be on the 5v side of things so it'll be electrically identical.

 

Then, on the expansion-box side, I'll put down an actual cartridge port, and we'll see if I can get #1 to work well enough. It means I'll be paying out for some level-converters that I may never use, but I think that's the best compromise - level converters are relatively cheap. Given that I'm now going with a serialised interface, it's less likely than a "99% solution" - however, we can but try...

 

Serialising will happen over a USB-C connection interface to get the bandwidth up, I'll be running the interface as fast as possible (ideally at ~2 GBit/sec in the host->expansion-box direction and 1 GBit/sec in the expansion-box -> host direction using the built-in SERDES hardware on the Spartan6 LX9). I won't lie, this is a more challenging approach, but there's a bunch of people around here I can ask for help with, and it's only really the cartridge port that would be the driver of needing such high bandwidth - if it doesn't work out, well, there's still the cartridge pinouts on the host-side, and I can get the interface to run a lot slower (which is not so challenging )

 

What it will mean is that the entire box will connect with just a standard USB-C cable to the host-board, which is quite elegant

 

On the plus side, I think I've figured out how to get video output on the cheap from the STM32, ie: without using an expensive HDMI chip or video-dac. I'm pretty sure I can bind the LTDC controller to VGA pins using only some resistors (in an R-2R ladder), diodes for signal integrity, and a couple of FETs for the sync signals. Using 1% resistors (still dirt-cheap) ought to give reasonable accuracy and all these components are literally pennies. There's plenty of monitors that can take VGA still, so I think this is a win.

 

So the expansion box will supply USB (Host only, so mouse/keyboard can be attached), 5 expansion slots, possibly a cartridge port, 2 serial ports, an SD-card interface, and VGA video but no ethernet. I've dropped the joystick interface to the expansion slots (I couldn't think of anything that really wanted read-only joystick values and I didn't have the pins to make it writeable) although SIO is still available on each slot. I think that's a reasonable compromise

 

.

.

.

 

In the spirit of Steve Jobs... "There's one more thing..."

 

The main job of the LX9 FPGAs is to serialise/de-serialise the data as fast as physically possible. That's their raison d'être and it's both a necessary and sufficient reason for their inclusion. However...

 

The SerDes logic is (mainly) built into the IoBuf pin functionality. Sure, I have to set up multiple clocks, manage data-flow, possibly train the link to make sure we're getting a good signal-to-noise ratio, and a whole bunch of other logic if I want error-correction. That's a job of work, and it'll be the only focus until it's done. The thing is, it's not a lot of space in terms of how many look-up-tables are required. There's almost an embarrassment of riches there, and FPGAs do things in parallel - there's no real impact on existing logic, if you add more functionality (up to about 70% or so utilisation of the FPGA, after that routing can be an issue, especially on the Spartan-6).

 

Soooo.... There's a 6502 core by Arlet Ottens that, when synthesized for a Spartan-6, reached about 111 MHz, or approximately 60x the original A8. The A8 would obviously still be in charge of its hardware and i/o, but since the core can execute the *same* code, and since that code can be located in a memory aperture mapped to the A8's bus, well, there's a lot of possibility there. If I can put my theory of how to take over the CPU's bus successfully to the test, then DLI's can suddenly do a lot more, for example Oh, and the 6502 core is small - very small. It's entirely possible we could get up to 8 or so of them in there...

 

Just food for thought - as I said above, the plan is to deliver on the existing project before attempting anything else...

 

Simon

[+mytek]

I'll put down a full pin-out of the cartridge port on the host-side board, to which something similar to DropCheck's board could be attached. I don't know if I'll put down an actual cartridge port, probably just pin-headers, but it'll work the same way as a cartridge port, all the signals will be there. This will be on the 5v side of things so it'll be electrically identical.

 

To keep it compatible with Dropcheck's board, which BTW works great, I would kindly suggest that you consider going with a 'real' edge card connection instead of a pin header. That way her board can plug right in without any adaption required. And there really isn't much space or cost savings to be had by substituting a pin header instead.

 

These edge card connectors are pretty cheap as is, being less than $3 in single quantity buys (Arrow sells them for $2.31 each), and they are readily available from multiple sources.

Digi-Key P/N: A31715-ND

Mouser P/N: 571-5530843-2

Newark P/N: 77M1924

Arrow P/N: 5530843-2

 

 

Serialising will happen over a USB-C connection interface to get the bandwidth up, I'll be running the interface as fast as possible (ideally at ~2 GBit/sec in the host->expansion-box direction and 1 GBit/sec in the expansion-box -> host direction using the built-in SERDES hardware on the Spartan6 LX9). I won't lie, this is a more challenging approach, but there's a bunch of people around here I can ask for help with, and it's only really the cartridge port that would be the driver of needing such high bandwidth - if it doesn't work out, well, there's still the cartridge pinouts on the host-side, and I can get the interface to run a lot slower (which is not so challenging )

 

What it will mean is that the entire box will connect with just a standard USB-C cable to the host-board, which is quite elegant

 

I like this a lot. This is much better than having a bulky wide ribbon cable connection as was the case on the original 1090 design. Any idea on how small the interface board can be made?

 

I gotta say this is looking to be a very complex project, much more so then anything I've ever seen suggested and/or tackled for the A8. I wish you much success, but at the same time don't envy the work that will be required to bring this into reality.

 

Great stuff indeed .

[+Spaced Cowboy]

To keep it compatible with Dropcheck's board, which BTW works great, I would kindly suggest that you consider going with a 'real' edge card connection instead of a pin header. That way her board can plug right in without any adaption required. And there really isn't much space or cost savings to be had by substituting a pin header instead.

 

These edge card connectors are pretty cheap as is, being less than $3 in single quantity buys (Arrow sells them for $2.31 each), and they are readily available from multiple sources.

Digi-Key P/N: A31715-ND

Mouser P/N: 571-5530843-2

Newark P/N: 77M1924

Arrow P/N: 5530843-2

Yeah, it's more placement than saving space that I'm concerned about. The host-interface will be machine-specific anyway (the 800XL has the parallel bus, the XE and the 1088XEL both have ECI, but the Realan H80 case for the 1088XEL puts height-constraints on the PCB, which conflicts with the XE wanting a lot of PCB dedicated to the ECI pins because of the geometry of the back of its case). My best-case for the 1088XEL is to put the cartridge port towards the bottom of the board (so it's close to the 5v pins coming from the motherboard) but I wasn't sure about clearance in that case (pun intended). I need to take more measurements and I still don't have a great solution for where (in that case) dropcheck's board would fit. Perhaps a custom back-panel .

 

On the other hand, if you go for a larger mini-ITX case, the problem disappears. If only the H80 wasn't the "go-to" case for the 1088XEL, life would be easier

 

I like this a lot. This is much better than having a bulky wide ribbon cable connection as was the case on the original 1090 design. Any idea on how small the interface board can be made?

 

I gotta say this is looking to be a very complex project, much more so then anything I've ever seen suggested and/or tackled for the A8. I wish you much success, but at the same time don't envy the work that will be required to bring this into reality.

 

Great stuff indeed .

 

It *is* more complex, and as a software-guy, this is probably the most-challenging thing I've taken on. The good thing is that I'm surrounded by experts in the field - and I'm not afraid to use them

 

The interface board itself will have 4 major functional areas

• Level translation from 5v to 3.3. Everything in the expansion box will run at 3.3v apart from the cartridge pins
• FPGA to do the SerDes operations (along with anything else I can cram in there afterwards
• SDRAM to handle the memory without going over the link. SDRAM is cheap, and I can write an interface relatively easily I think.
• USB-c socket and the relevant PCB layout. This will actually be the first thing I do when I lay out the host board - everything else will be worked in around that.

So the board itself *could* be pretty small - but I'll probably want to make it larger than strictly necessary so that the USB-c socket can mate seamlessly with the back-panel. At the sort of speeds we're talking about the interface running, it has to go directly from [cable]<-->[uSB-c socket]<-->[FPGA], there can't be any intervening wiring, so if we want the USB-c cable to plug in the back, the board has to extend that far. I could always make it so that the cable went through a grommet and plugged in internally, but I don't think that's as nice or functional.

 

One other thing I ought to point out in case it's not clear - I'm using the USB-c as an electrical interface only - I'm not running real USB-c. You won't be able to plug in a USB-c device to this socket and expect anything to work - I just need a simple interface which has a sufficient number of high-speed differential-pair wires in an easy-to-get-hold-of form-factor.

 

Cheers

Simon