Dev board updates from Kevin Williams

[TomXP411]

From @Kevin Williams, via Discord:

Hey everyone.  It's taking a bit longer than I planned, but here is the current state of the X16 Developer Board.  I'm still routing it and I do need to nudge a few things around and stuff can happen, but this is more or less the layout I'll be going with.  It is a little different than Proto 3, and perhaps a bit more than planned which is part of the reason it has been taking longer.  For one, after adding Wavicle's clock stretching circuit, I felt the urge to revisit some of my decoding logic and was able to simplify it a little and move some things around.  I undid a part of my logic (interestingly, something Adrian and I added) that was incompatible with the clock stretching and wound up saving another IC.  But then, I subsequently put another IC on the board for another feature, ROM carts.  A total of 2MB of RAM is accessible via 256 'pages' of 8k each in the HI-RAM area.  The ROM functionally works the same, but we only have 512k onboard and a 16k window.  We could theoretically support up to 4MB of ROM with this arrangement but, 512k is probably more than enough.  Looking down the road however, David suggested moving these pins to the bus so we could later support a cartridge.  I did quite a bit of shuffling of pins on the bus and managed to squeeze everything we wanted in there, for the most part.  I'm sure some may disagree, but 60 pins are all we have.  Some other parts have been moved to hopefully optimize the audio ground paths, as well as other ground considerations.  Pretty happy with it, but the board is pretty crowded now.

Some other notes and changes:

I decided not to change the expansion port.  I intentionally picked 60 pins on Proto 3 because it's uncommon and a lot of pins.  This prevents A2 & ISA cards and I think none of the console carts will fit in here, maybe Famicom?  But hey, it is its own thing, so please, only X16 stuff!  I'm thinking about printing it on the production PCB.

Image

Added a ton of UGLY TVS Diodes for port protection.  I think they will be a little less ugly in real-life, but safety third, or something.

Added a relay on the audio circuit to mute it on reset or power off.  The caps on the opamps make a squeal when powering off, and the YM tends to squeal a hair too, so I wanted it to mute to prevent spurious noise.  I know a relay may be annoying, but it truly is the best ‘invisible’ mute circuit in my opinion.

I moved the ATX power connector to a more traditional location on the side of the board.  IE, a more traditional location.

The last big one, was something I wanted to add, which is an audio-option header.  I haven’t labeled much of anything in this pic yet, but the header directly to the left of the power connector is meant for an add-on audio board.  Directly to the right of the connector are several on-board jumper pads which can be cut, and optional PCBs can be designed to do some cool stuff.  We don’t really have a volume control, except via SW, but this header has the VERA, YM & BUS audio input pins individual addressable, the output opamp is still there, as well as the i2c pins.  So you could get an i2c variable pot to set volumes, with code!  You could also add effects, and all manner of cool stuff!  Or leave it alone and it still works as it did originally.

I’m probably forgetting something, but that is the bulk of it.  It’s a daunting board to layout, and it takes a ton of optimization.  However, I really want the dev board to be as close to the prod as possible to make sure we work out any issues now before we start making a TON more. 

Take care everyone and thanks for your involvement.  I truly will be the software available which makes this machine successful, and I have high hopes for what we can achieve, it’s really the best DIY made in many years in my opinion.  Yes, I am biased, but I do think it’s true in this case

[BruceMcF]

Note no motherboard User Port, which had been raised by Kevin on Facebook as a possibility ... the I2C pin header is one pin short of being able to bring out PB0-2, CA1/2 & CB1/2, and since he mentions the routing being tight, the routing might not work anyway.

Since the serial shift register is needed for IEC burst mode, bringing out PB0-2 & CA1/2 on the I2C pin header NCs and redundant GNDs and wiring CB1/2 to support burst mode on the IEC port bears mentioning.

[Kalvan]

Well, the original Nintendo Famicom used a 60 pin pinout, as did the Atari 2600.  Since the compression method of the Nintendo S-DD1 chip has been cracked, I think that 512K should be plenty for a cartridge slot, so long as that chip (or a softcore of it on an FPGA) is on a plugged in expansion card.

So long as the expansion architecture allows expansion cards to augment, rather than simply replace the capabilities of VERA and the sound interface (merely removing scanline limits and/or allowing the display of all sprites at maximum size, or adding in an extra wavetable or PCM chip while still allowing normal use of the geometry channels and the YM2151, as examples), and preferably without requiring their own specific outputs to the monitor and/or speakers, I'll be happy indeed.

[NickMilner]

It's sure a thing of beauty. Massive respect to everyone involved.

[BruceMcF]

On 10/27/2022 at 8:01 PM, Kalvan said:

So long as the expansion architecture allows expansion cards to augment, rather than simply replace the capabilities of VERA and the sound interface (merely removing scanline limits and/or allowing the display of all sprites at maximum size, or adding in an extra wavetable or PCM chip while still allowing normal use of the geometry channels and the YM2151, as examples), ...

It would allow a bus mastering card to use the capabilities of the Vera.

But the Vera does what it does. The wiring of the Vera logic resources is not going to be modified by anything plugged into the expansion port, any more than anything plugged into a C64 cartridge port would modify the operation of the VIC-II video chip.

The expansion board card does show it still has Audio_Right and Audio_Left, so mixing what is done by the built in X16 audio source (FM chip, PSD & PCM) with additional resources on an expansion card (SID, MIDI Wavetable, etc.) seems like it would be definitely do-able.

[neutrino]

On 10/27/2022 at 7:47 PM, TomXP411 said:

I intentionally picked 60 pins on Proto 3 because it's uncommon and a lot of pins.  This prevents A2 & ISA cards and I think none of the console carts will fit in here, maybe Famicom?  But hey, it is its own thing, so please, only X16 stuff!

It should be sufficient to put a label on the motherboard "Commander X16 expansion slot". It's up to the user to be responsible enough, to pay attention to markings.

Also, markings as to which hardware version the board complies to might be useful. Like "X16 version 1.234 pin layout version 5" where if the pins change meaning or location a user can know right away.

Non-common connector parts might be an issue with supply chains possibly. (like the DB23 for the Amiga)

Useful pins could be provided with a simple solder pad for modifications, expansions or plain debugging. (like on the C64 Direct-to-TV)

Should the pins for the existing expansion bus be insufficient it would be possible to reduce the number of ROM pins by providing a ROM address instead of a fully decoded output.

On 10/28/2022 at 2:01 AM, Kalvan said:

rather than simply replace the capabilities of VERA

It can be handled by the same setup the 3Dfx cards used on the PC. Physically route the video output through an expansion card, and then connect the monitor to the output connector.

[BruceMcF]

On 10/29/2022 at 6:33 AM, neutrino said:

Should the pins for the existing expansion bus be insufficient it would be possible to reduce the number of ROM pins by providing a ROM address instead of a fully decoded output.

Look at the picture. It is a ROM address, not a fully decoded output.

 

On 10/29/2022 at 6:33 AM, neutrino said:

It can be handled by the same setup the 3Dfx cards used on the PC. Physically route the video output through an expansion card, and then connect the monitor to the output connector.

RTFM, it is analog video outputs from Vera.

[neutrino]

On 10/29/2022 at 4:46 PM, BruceMcF said:

RTFM, it is analog video outputs from Vera.

Analog signals can be exploited, The 3Dfx Vodoo2 system used analog VGA female and male connectors to route the video signal through the card. An analog switch can then be used to insert extra graphics capability were desired. The PAL/NTSC teletext subtitling function uses the same principle.

On 10/29/2022 at 4:46 PM, BruceMcF said:

Look at the picture. It is a ROM address, not a fully decoded output.

The picture just says ROMB0 - ROMB7 and the FAQ specifies 32 banks ie 5-bits but not how much will be present on the expansion bus. There's no pinout description nor any schematic asfaik. So the board isn't self evident in function.

[Main Administrator]

Another message from @Kevin Williams on Facebook:



The big take-aways from this one:

• 
  Target 512KB of RAM. Future systems will be limited to this, with 2MB for "power user" systems, such as developers
  


• 
  Rough estimate of retail sales is: "Christmas of next year." 
  

https://www.facebook.com/groups/CommanderX16/permalink/1285577575526667/

Quote

The purpose of the development run is really two-fold. One is to get the hardware into the hands of early developers. We already have a lot of folks developing on the emulator, but it's not a complete substitution for the real thing in all cases, so the idea is to get a head start on development for the final release.

Secondly, I want to make sure the system is stable. We have had the system running code for some time now, but only in the last six months were we able to actually validate that everything was working correctly. Wavicle and some other members of the Discord team had found that the YM2151 was not terribly happy at 8MHz. While it was working, it was dropping some data at times, and reads from the IC were also not terribly reliable. I sort of knew this might happen, but had never been able to test to a level where I could fully validate it. They were able to come up with a clock streching circuit to effectively slow reads and writes down to 2MHz for slower devices. This change is now on the dev board, and has been tested for a little while now. The really cool thing about this addition is that pretty much any device that will work at 2MHz or faster will now run directly on the bus! IE, you could cram a SID or two on an expansion card if you really wanted to.

We want to chase any other gremlins out of the system before shipping, so the other part of the dev run is to have folks beat on the HW to make sure everything is working as we hope. I know 95% is the magic number for still not finished, but I really meant 95% done routing this particular board, not the HW itself. What I believe is more at question, is what software will ship with the system at launch.





This is where the magic is, IMO. 2MB of RAM happened, because of math, not because it was necessarily a good idea. I mean, who doesn't want more RAM, but do you need it? The banks for RAM and ROM are stored in an 8-bit shift register, so I have 256 'banks' of 8k on the RAM available. This equals 2MB. Likewise, the ROM has a 16k window with 256 banks, so 4MB of ROM. In reality, they could both be RAM or ROM, but the two windows are there. But as stated, I just put 2MB on there, because I could, not because it was a good idea. The ROM was originally only 128K, then 512K, but now the whole range is accessible via the expansion port.

However, as the system has evolved, we know loading data from the SD card is plenty fast for you to swap out data in the 512k range. The only real reason to have 2MB would be for laziness. � 512k should be plenty for most games, but, David actually came up with an interesting idea. Let's say you're a developer, with 2MB, you would have enough RAM to run a compiler environment in the top 1.5mb, then compile and run the code directly on the system, but only using the lower 512k. I can imagine an OS like GEOS would benefit from the RAM, and I think eventually, this machine could be used for music composition, so 2MB of RAM would be handy for more sample time. Pretty sure the Roland S550 I used to own in the 90s had 2MB or heck, maybe 1MB. Point is, there are times when you might be able to use it, but for gaming, 512k is probably going to be fine.





The next versions of the system will likely be capped at 512k of high RAM, so the message we want to send to developers is use 512k. For power users, this version of the system will always be the go-to version as it will allow you the most flexibility. But, the more cost reduced versions will be less capable, but still run all of the games available and likely other SW with reduced capacity. IE, I have less sample time, or less RAM for GEOS, etc.





There are a lot of exciting tools in the works as well for the system, so I really hope that this is one of the most complete 8-bit homebrew systems ever, before we launch! This will give developers a really easy path to getting stuff up and running, and will offer features that no other 8-bit machine has seen. I think it was Steve Ballmer that said, "It's the software, stupid!", in this case, I think he is correct. We should have a lot to offer before day 1, and I really think it will only grow from there!

Note: Kevin will not see your responses to this post unless you tag him directly. 

 

[BruceMcF]

On 10/29/2022 at 11:20 AM, neutrino said:

The picture just says ROMB0 - ROMB7 and the FAQ specifies 32 banks ie 5-bits but not how much will be present on the expansion bus. There's no pinout description nor any schematic asfaik. So the board isn't self evident in function.

Since there is an 8bit latch holding the ROM bank specification, and the picture says ROMB0 - ROMB7, there is your answer right there: they are bringing out all of the ROM bank latch.