Beginning of very long journey

[czietz]

And while debugging that dreaded Falcon board board, I have also quite progressed on F030NG. Schematics, except for DSP and analog audio are now complete, LAN and USB are in place. I have also did a first version of board layout.

Very nice! Which chip will you be using for USB?

[mpattonm]

LAN and USB are basically on-board NetUSBee implementation, so current drivers should work out of the box.
USB: Phillips ISP1160
LAN: Realtek RTL8019AS

[czietz]

USB: Phillips ISP1160

In the Lightning VME we're using this one as well, basically for the same reason: drivers.

Just be warned that you'll encounter some supply-chain issues with the ISP1160. It's long discontinued, hence it is only available at more or less dubious obsolete parts dealers. During manufacture of the Lightning VME we encountered among other things: 1. ISP1160s where the leads were corroded to such a degree that -- even though we extensively cleaned them -- we suffered a huge yield loss due to poor solderability. 2. A shipment of ISP1160s -- claiming to be new-old stock -- in which more than half of them were basically dead, one of the power pins being shorted to ground. They must have been used and severely mistreated during their previous life to fail in such an obvious way. 3. Some random faults within the chip that are fortunately caught during our end-of-line test.

All I want to say: Be sure not to buy from the cheapest source and prepare to have some issues with that chip.

[mpattonm]

Shoot. I have realized they are harder to obtain, but I have not expect the situation to be that bad. Do you have an experience with, or have you considered ISP1161? They are more recent than 1160.

[czietz]

I think ISP1161 is actually the same silicon as ISP1160, only that the USB device controller part is enabled as well -- but you don't need to use it, of course. So I'd expect ISP1161 to work right out of the box. I (or we as the Lightning VME team) don't have any experience with the ISP1161, though.

Matthias, who is in charge of purchasing and build-up, has found a batch of working ISP1160. So it's not impossible to find them; you just might have bad luck, like we did several times.

[Galvez]

LAN and USB are basically on-board NetUSBee implementation, so current drivers should work out of the box.

Could you explain further please how will you do that? To avoid conflicts with the real ROM-port I mean.

Great work but the way!

[mpattonm]

For this revision, the only solution is to disable XROM3 and XROM4 signals routes to both chips via on-board jumper, whenever you want to use ROM port cartridge.
There is also unused serial interface in MFP, that could potentially used to manage whole lot of additional devices and that could be SW driven solution. I have not explored this option futher, is not on a plate for now.

[mikro]

When it comes to ethernet, what about something like this: viewtopic.php?f=27&t=28840 but built in?

I have that card, it's the same IC so I had adapted the original EtherNEC drivers for that + optimised the hell out of it (plus enabled 16-bit transfers), it's quite fast in the end: viewtopic.php?f=27&t=28840&start=50#p307838

[viking272]

Really enjoy these updates.

I found this interesting video on youtube, about going to manufacture with your PCB Design. Really good tips and ideas.
Do board designers typically source their own materials and send to China for production? Or do they take a Bill of Materials and then quote to buy and build?
https://www.youtube.com/watch?v=VXE_dh38HjU

[joska]

When it comes to ethernet, what about something like this: http://www.atari-forum.com/viewtopic.php?f=27&t=28840 but built in?

Will this work with a CT60x?

[mpattonm]

Good question, the compatibility with existing CT6X is one of my goals. Either way, what mikro suggest is very interesting piece of hardware, based on RTL chip driven by Altera CPLD. I would like to have this postponed for next revision, where I hope to implement large enough FPGA, which should the contain more then LAN and USB logic.

[mpattonm]

Just a little progress: DSP schematic and layout is in place, the only real missing part now is analog audio circuity.
After that, which should not take more than a week, I will spend some time on clock circuits and then routing commence.

[mpattonm]

Airwires off. As you might notice, there are some more layout changes from last version: RAM, SCSI, VGA and TV-OUT were relocated. This resulted in shorter aiwires and I could properly position FDD footprint in there as well now.

[TheNameOfTheGame]

Nice! Thanks for the update!

[mikro]

Just found in the 56002 manual, which might become a problem:

Note: The difference between Modes 1 and 5 in the DSP56002 and Mode 1 in the
DSP56001 may be considered software incompatibility. A DSP56001 program that
reloads the internal P: RAM from the Host Port by setting MB-MA = 01 (assuming
external pull-up resistor on bit 23 of P:$C000) will not work correctly in the
DSP56002. In the DSP56002, the program would trigger a bootstrap from the exter-
nal EPROM. The solution is to modify the DSP56001 program to set MC-MA = 101.

I found some time to look into this deeper. It's not as bad as it sounds. Usually what happens is that you reset the DSP externally and bootstrap some code into it. What this paragraph says that *if* some DSP program really loves to do this internally (i.e. in an already bootstrapped state), this wont work because the bootstrapping would occur from an external EPROM instead of the host port.

I looked into some well known "system" DSP programs, none of them is doing this (why would they, right?). Usually you use OMR register to switch ROMs, bootstrapping is done externally (a well known example is the MP2 player / routine which installs its own bootstrapping code *from outside*).

So if DSP56002 is easier / more fun / offers more functionality, go for it.

[mpattonm]

Well I have DSP56001 already in place, but I can change it for something else. But lets make it even more fun - another option could be DSP56301, supposedly code compatible with DSP56001 but with more features and horsepower too.

[mikro]

Oh man, that would be something. Deese card after so many years. In a standard Falcon!

[mpattonm]

Another question came to my mind - what would you find more benefitial fo SCSI - an external (Falcon type) connector, or rather an internal pinheader? When I think about it, I am inclined to go for an internal PH. An external connector could be added via riser card, afterall.
What do you think?

[mikro]

With the CosmosEx in mind, yes, an internal solution would be way better. AFAIK there was very limited use of the external connector -- many tower owners would transform it into the classic flat SCSI cable anyway.

Perhaps there are still people having only one external SCSI device (or people willing to have the CE externally) but I'd say majority of use cases are better suited with an internal connector.

[shoggoth]

With the CosmosEx in mind, yes, an internal solution would be way better. AFAIK there was very limited use of the external connector -- many tower owners would transform it into the classic flat SCSI cable anyway.

Perhaps there are still people having only one external SCSI device (or people willing to have the CE externally) but I'd say majority of use cases are better suited with an internal connector.

One is easier to convert to the other than the other way around:
https://www.itead.cc/scsi2-50pin-to-scs ... apter.html

So... an internal header makes sense from that perspective.

[mpattonm]

Switching DSP to 56301 will be a little setback, but hey - its a fun project and thats where the fun is. So back to the schematics.

Anyway, I have layed out the redesigned clock subsystem concept, here it is.
Basically, most of the big cans and crystal resonators will be replaces by a single PLL chip. The main clock will be user selectable from 32,34,36,38,40,44,48,52 MHz options. Overclocking the system bus will however not overclock I/O subsystem so that should remain stable. DSP will have an independent clock source (again from PLL).
If there is enough room, I will also implement DIP-16 socket for original 32,084988MHz crystal generator. With that in place, user will have an option to switch from generic PLL to original Falcon clock frequencies for RGB monitor support and cycle-perfect Falcon demo compatibility.
Opinions, please?

[mikro]

Switching DSP to 56301 will be a little setback, but hey - its a fun project and thats where the fun is. So back to the schematics.

Awesome. Just want to mention it - in this case some minor changes to the TOS are going to be needed.

Overclocking the system bus will however not overclock I/O subsystem so that should remain stable.

Are you sure that NG schematics reflect that idea? I mean you're still sourcing the SDMA with CPUCLKA so whatever happens in the Combel will get mirrored on the output. In this particular case, ACIAs wont work anymore (CLK8).

I'm not sure how all the issues related to clock patching will matter there now (I hope they wont at all), so in an ideal case I would do:

- have separate CLK8 for ACIAs coming from your PLL
- have CPUCLKA-C as in your schematics but with that exception that I would allow yet another source for the CPU/FPU - for the cases where one would replace CPU/FPU with their PGA variants (33-50 MHz, possible overclocking >50 MHz!)

In case the troubles with clock signals remain even in your new design, then I would definitely cut CPUCLKA + CPUCLKB from the Combel and had them sourced separately as the CenturboII does.

If there is enough room, I will also implement DIP-16 socket for original 32,084988MHz crystal generator. With that in place, user will have an option to switch from generic PLL to original Falcon clock frequencies for RGB monitor support and cycle-perfect Falcon demo compatibility.

Actually all you need is to drive this signal to Videl's VID32 pin (other turbo cards usually did this on the external pin but that resulted in 50% compatibility - yes, you could patch system calls but all demos using Videl's 32 MHz directly refuse to work without a patch).

EDIT: OK, I got confused. ACIA takes 500 kHz and yes, your schematics do reflect that. :-P

[mpattonm]

Are you sure that NG schematics reflect that idea? I mean you're still sourcing the SDMA with CPUCLKA so whatever happens in the Combel will get mirrored on the output. In this particular case, ACIAs wont work anymore (CLK8).

I thought KHZ500 is crutial from this point of view, is it not?

I'm not sure how all the issues related to clock patching will matter there now (I hope they wont at all), so in an ideal case I would do:
...
- have CPUCLKA-C as in your schematics but with that exception that I would allow yet another source for the CPU/FPU - for the cases where one would replace CPU/FPU with their PGA variants (33-50 MHz, possible overclocking >50 MHz!)

Fair enough. I could do this.

In case the troubles with clock signals remain even in your new design...

That certainly should not happen, it would be really pitty.

Actually all you need is to drive this signal to Videl's VID32 pin (other turbo cards usually did this on the external pin but that resulted in 50% compatibility - yes, you could patch system calls but all demos using Videl's 32 MHz directly refuse to work without a patch).

So you are saying that VIDEL can work on asynchronous clock from the rest of components? I mean would scenario where the Videl is fed from 32,08... crystal, while CPU + FPU + exp.port and namely DMA are fed 40(/2) Mhz from (unsynced) PLL work?

[mpattonm]

EDIT: OK, I got confused. ACIA takes 500 kHz and yes, your schematics do reflect that.

Ah, ok.

[mpattonm]

One thing I do not understand well is, why SDMA is fed not only main CPU clock (16,04..MHz CPUCLKA signal), but also 25,175 MHz from VIDEL and especially, 32MHz from DSP.
I mean - CLK8, CLK4, CLK2 and KHZ5000 are derivated from CPUCLKA (correct?), what is the purpose?