Beginning of very long journey

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

czietz
Hardware Guru
Hardware Guru
Posts: 782
Joined: Tue May 24, 2016 6:47 pm

Re: Beginning of very long journey

Postby czietz » Sun Sep 16, 2018 7:02 am

mpattonm wrote: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
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Sun Sep 16, 2018 8:55 am

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
Hardware Guru
Hardware Guru
Posts: 782
Joined: Tue May 24, 2016 6:47 pm

Re: Beginning of very long journey

Postby czietz » Sun Sep 16, 2018 9:12 am

mpattonm wrote: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
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Sun Sep 16, 2018 12:25 pm

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
Hardware Guru
Hardware Guru
Posts: 782
Joined: Tue May 24, 2016 6:47 pm

Re: Beginning of very long journey

Postby czietz » Sun Sep 16, 2018 12:39 pm

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
Captain Atari
Captain Atari
Posts: 240
Joined: Fri Oct 19, 2007 7:49 am

Re: Beginning of very long journey

Postby Galvez » Sun Sep 16, 2018 2:56 pm

mpattonm wrote: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
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Sun Sep 16, 2018 9:05 pm

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
Hardware Guru
Hardware Guru
Posts: 1782
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Mon Sep 17, 2018 6:06 am

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

User avatar
viking272
Captain Atari
Captain Atari
Posts: 367
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Beginning of very long journey

Postby viking272 » Fri Sep 21, 2018 9:37 am

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
Hardware Guru
Hardware Guru
Posts: 4177
Joined: Tue Oct 30, 2007 2:55 pm
Location: Florø, Norway
Contact:

Re: Beginning of very long journey

Postby joska » Fri Sep 21, 2018 12:08 pm

mikro wrote: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?
Jo Even

VanillaMiNT - Firebee - Falcon060 - Milan060 - Falcon040 - MIST - Mega ST - STM - STE - Amiga 600 - Sharp MZ700 - MSX - Amstrad CPC - C64

mpattonm
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Sep 21, 2018 12:16 pm

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
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Thu Sep 27, 2018 12:22 pm

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.
You do not have the required permissions to view the files attached to this post.

mpattonm
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Thu Sep 27, 2018 12:26 pm

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.
You do not have the required permissions to view the files attached to this post.

User avatar
TheNameOfTheGame
Atari God
Atari God
Posts: 1104
Joined: Mon Jul 23, 2012 8:57 pm
Location: Almost Heaven, West Virginia

Re: Beginning of very long journey

Postby TheNameOfTheGame » Sat Sep 29, 2018 4:23 pm

Nice! Thanks for the update!

mikro
Hardware Guru
Hardware Guru
Posts: 1782
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Wed Oct 10, 2018 11:28 am

ThorstenOtto wrote: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
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Wed Oct 10, 2018 12:24 pm

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
Hardware Guru
Hardware Guru
Posts: 1782
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Wed Oct 10, 2018 12:26 pm

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

mpattonm
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Wed Oct 10, 2018 12:34 pm

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
Hardware Guru
Hardware Guru
Posts: 1782
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Wed Oct 10, 2018 12:44 pm

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.

User avatar
shoggoth
Nature
Nature
Posts: 951
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: Beginning of very long journey

Postby shoggoth » Thu Oct 11, 2018 8:09 am

mikro wrote: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.
Ain't no space like PeP-space.

mpattonm
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 9:50 am

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?
You do not have the required permissions to view the files attached to this post.

mikro
Hardware Guru
Hardware Guru
Posts: 1782
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: Beginning of very long journey

Postby mikro » Fri Oct 12, 2018 10:41 am

mpattonm wrote: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
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 12:04 pm

mikro wrote: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?
mikro wrote: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.
mikro wrote:In case the troubles with clock signals remain even in your new design...

That certainly should not happen, it would be really pitty.
mikro wrote: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?
Last edited by mpattonm on Fri Oct 12, 2018 12:15 pm, edited 4 times in total.

mpattonm
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 12:05 pm

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

Ah, ok.

mpattonm
Hardware Guru
Hardware Guru
Posts: 337
Joined: Mon Oct 21, 2002 8:52 am
Location: Czech republic
Contact:

Re: Beginning of very long journey

Postby mpattonm » Fri Oct 12, 2018 12:14 pm

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?


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 5 guests