Home » RBC Forums » General Discussion » Building a SBC specifically for use with Fuzix (Ideas / feedback wanted for new SBC project)
 Building a SBC specifically for use with Fuzix [message #9878] |
Fri, 29 April 2022 02:51  |
sebastian
Messages: 12
Registered: April 2017
|
Junior Member |
|
|
Note: There are still many parts of this I don't understand, and I'm aware it's an ambitious project expected to take months at best, certainly not something for a weekend or so. This is a rough draft of a project idea to collect input, feedback and see about its feasibility. If something comes of this, of course all results are meant to be shared with the public (including boards and parts from my side, if anybody is interested). Input from experienced forum members is very welcome. Maybe Alan Cox himself will notice this, who knows?
Also, yes, I did read the parts of Fuzix documentation about porting and memory management, but I'm not an experienced systems developer and don't think I can do all the work alone.
Motivation:
Ever since I heard about Fuzix, I've been fascinated with the concept of this operating system, because it really fills a gap, between homebuilt computers of manageable complexity that run CP/M at best, and Linux-capable computers that require sophisticated tools and lots of specialized knowledge to build. Unix-like features in a retro home computer, or a "modern" one an electronics hobbyist can hand-solder on a double-sided PCB, or even wire-wrap, that's something hard to find.
Since there are a lot of classic and homebuilt 8-bit platforms already, maybe adding a homebuilt 16-bit SBC that offers sufficient RAM and CPU power to enable application development on the system itself, IMHO a distinguishing feature between a microcontroller system and a "real" computer - even if that has been a blurry distinction historically - could be worthwhile.
Candidates of interest:
Since there is a HC11 port already, the HC12 variant for external memory, MC812A4CPVE8 (still available) seems like a possible target for Fuzix, despite being designed as a microcontroller. This part has a MMU integrated, however this is meant to handle "program space" in 16k pages and "data space" in 4k pages - the distinction between program and data space seems a bit arbitrary, since a HC12 should be able to run code from RAM (even from internal EEPROM) in general, as long as it can be reached within its address space. Personally, I still don't entirely understand the scheme of mapping the internal pages to chip select lines on the outside, so I can't really say if this part lends itself to Fuzix well, or if the MMU is too specific and can't be configured in a way useful to it.
Alternatively, there's the MC68302, no longer manufactured, but easily found through sources available to the hobbyist. The "communications processor" (as marketed by its creators) is basically a 68EC000 (so the m68k port would be a good basis) with a peripheral subsystem in a package, and a full 8- or 16-bit bus (DMA capable) towards the outside world. Just like with a real 68000 or 68010, there's no MMU, but a large flat memory model. Interestingly, using a bit of assembly code in external rom (which is accessed first at startup), the RAM memory could be remapped to start at address $0 (even after copying the OS to it).
Important features:
512k of SRAM are probably a good starting point. Both chips would be able to address significantly more.
Communication interfaces (UART/SPI, etc.) are available on-chip already.
For external storage, I've got three ideas, which could be used alternatively, or combined:
- Classic 34-pin SHUGART bus floppy drive as used in PCs (via 37C65 FDC)
- IDE interface (should attach to a 16-bit bus easily, can support DiskOnModule on top of old HDDs, or CF cards in a simple adapter)
- CH375 chip, a modern "black box" (internal firmware invisible to user) USB host controller with serial/parallel interface, presenting USB storage to the system on an abstraction level that would make writing a driver easy (read/write function for 512 byte blocks)
Admittedly, SD card directly interfaced to SPI would be a popular option too, but I never worked with that and don't know if it's readily usable.
There has been talk about TCP/IP being worked on. In this light, ethernet connectivity could be an useful add-on. I'd suggest the CS8900A chip for this; even though it has recently been declared "end-of-life" by ist manufacturer, these chips are still around in some quantities. Unlike the venerable RTL8019AS, the CS8900A has the advantage of doing checksum generation and verification independently from a host CPU.
Questions:
For a system configuration as roughly outlined above, relatively large CPU and probably half a megabyte of SRAM, which of the two sounds like the better option, HC812A4 or 68302? Or would it be way easier to go with a regular 68000/68010?
What is the preferred way of using Fuzix, placing it in a ROM at a fixed address, or copying it to RAM by some kind of monitor / boot loader and jumping to its start address?
How would a sensible memory map look like in a HC12 or m68k system? Start address for Fuzix itself or application memory, does it matter? Where should peripherals like the FDC or IDE port be mapped to, if one is used?
Links to documentation:
https://www.nxp.com/docs/en/data-sheet/MC68HC812A4.pdf
https://www.nxp.com/docs/en/reference-manual/MC68302UM.pdf
[Updated on: Fri, 29 April 2022 02:53] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9882 is a reply to message #9878] |
Sat, 30 April 2022 11:14  |
coredump
Messages: 33
Registered: January 2020
Location: Germany
|
Member |
|
|
Hi Sebastian,
just a few rather unsorted remarks:
- to write software _on_ the board You obviously need a compiler running on the board or You are stuck to assembler.
With 64KB local address space this sounds hard for the 68HC12. Is there something?
- A bare 68000 is nice and shining, but for a SBC You will need to include peripherals (at least Uart/timer) and quite a lot of glue. This quickly fills
a very affordable 100 x 100mm² PCB, will consume some time and maybe introduce mistakes that will consume even more time.
- 512KB is quickly filled up. A SBC with ethernet, IDE interface and maybe additional SD-Card might be also attractive for other things than FUZIX.
512KB x 16 and 1MB x 16 are also available as SRAM.
- to throw an other processor candidate into the race: MC68VZ328 runs at 33MHz (overclocking addicts can see it failing at 66MHz by changing a single bit..),
allows for glueless connection to 16MB x 16 SDRAM (not that so much is urgently needed, but it's cheap, small and simple done), comes with a
surprisingly simple bootstrap mode for testing the board and programming a soldered flash. And the included peripherals might be more useful
for a sbc than those in the MC68(EN)302. 'Handbook' and errata on the nxp-site.
- Ethernet: Maybe ENC624J600 is interesting. Larger RAM buffer than CS8900 (can also be used as SRAM during bootstrap). But this one I didn't play with myself.
So I can't say something about bugs.
- 100 x 100mm² PCB with 4 layers are 5pcs. at $8 from jlcpbc.com. This is nicely affordable, eases the layout job and ground plane plus VCC plane can save a
lot of trouble with rather fast parts.
- With MC68000, having RAM starting at 0 (after booting...) is highly recommended.
- Don't forget the RTC ;) .
Best Regards
Detlef
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9883 is a reply to message #9878] |
Sat, 30 April 2022 15:30 |
sebastian
Messages: 12
Registered: April 2017
|
Junior Member |
|
|
Thank you for your replies and suggestions. I'm hardly online on weekends, but I'll try to reply briefly at least:
@plasmo:
I've seen your impressive work on the wiki, the tiny302 is actually the only non-commercial '302 design I've seen so far. I take your post as a vote for the MC68302 over HC12 then. Actually I've got an industrial board at hand which could provide some design inspiration at least, and be depopulated for parts later, however with probably less than 10 of these still in existence, and an entirely undocumented product, it's probably not worth reverse engineering.
@lynchaj:
Interesting suggestions. I only did a quick market check, but it seems to me as if NS32016 seem to be relatively rare and already expensive, so IMHO probably best left to collectors and people who need spare parts, while enough Z8000 CPUs appear to be around and available for decent prices to make a new design seem worthwhile. The problem is: Both of these are probably not binary compatible with any architecture already supported by Fuzix, and porting the system (and tools) to a whole new architecture, instead of just adapting an existing one, is seriously beyond my skill level. If I could do that, I would feel tempted to pick something like Renesas M16C/80 (another large flat memory system) first, because there's at least a gcc port for M16C/M32C already.
@coredump:
Wow, that's a lot of input, I'll try to reply to each bit...
- If I'm not misinformed, Fuzix seems to come with a SmallC compiler already, and I suspect a resource-efficient interpreted language llike Lua could be ported to it. Sure the memory management of the HC12 only makes memory available in small blocks, but then, didn't early PCs (or generally x86 systems) work with 64k code/data segments too, while still able to handle larger applications?
- You're certainly right about board space. 100 x 100 mm would be a good size, 100 x 150 mm acceptable if necessary. This is an argument against the bare 68000, but the 68302 does have timers and UARTs built-in, so it contributes to a space-saving board layout.
- About memory, I didn't check prices for those really large SRAMs. They could be an option if affordable and available. Are you thinking about a specific operating system? Running Linux may require a lot more system resources, though I remember someone running a very old Linux version on a 68008 SBC.
- The MC68VZ328 is actually interesting, at first glance, I didn't know about it before. If the SDRAM routing is manageable, and the on-chip SDRAM controller doesn't require a lot of obscure configuration, this could be a possible alternative. SDRAM is cheaper than SRAM, and if I didn't miss anything, it's still a true m68k part.
- Indeed, ENC624J600 seems like an interesting device from its features. At this point I can't tell if it's easy to work with or not. Availability seems to be limited now due to the global chip shortage (no stock at Digi-Key, 52 weeks lead time - not looking any better with Mouser).
- Yes, 4 layers are affordable if sticking to 100 x 100 is possible. For a 33 MHz system, this could improve stability and make things easier. An option to consider, especially since I'd like to work with EasyEDA anyway, so jlcpcb is naturally the most convenient option.
- Good to know MC68000 systems prefer a RAM start address of 0. This seems to support the idea of just writing a small loader in assembly, which, placed in some EPROM or flash memory, copies a boot block / first track of media to RAM, while being filesystem-agnostic, and lets the operating system handle the rest from there... a bit similar to a non-UEFI PC BIOS, just without the BIOS function calls.
- The RTC is important. A serial (SPI) or parallel (8-bit) RTC, probably Seiko Epson, was always intended to be part of the design, with Dallas as a possible alternative.
Thank you so far! I'm still hoping for further contributions.
[Updated on: Sat, 30 April 2022 15:31] Report message to a moderator |
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9885 is a reply to message #9884] |
Sun, 01 May 2022 07:26 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
Hi
For the NS32016 there is a reference design by Bruce Culbert which ran an early version of Unix (I think it was a BSD -- possibly NetBSD) so assuming source code could be found then it would have a Unix variant and all its development tools. I implemented the Bruce Culbert NS32016 design in KiCAD a few years ago but it was never made into a board, so a lot of the hardware design work is done already. If the BSD variant could be recovered that would be a huge step towards a complete system.
A Z8000 system ran either CP/M-Z8K or a Mark Williams Coherent which is a Unix variant. I think the CP/M-Z8K is literally the source code for CP/M-68K retargeted for Z8000 and not a CP/M-80 derivative. The hitch with Z8000 is locating a reference design because they are few and far between. I am not saying they don't exist, but they have been a challenge to find. There might be a Zilog application note reference design somewhere. Unfortunately, I haven't found it yet.
https://hackaday.io/project/21934-z8000-testbed
https://www.kranenborg.org/z8000/
Either of these systems would be fit for a Fuzix port assuming building a reference hardware platform and then using some existing software as a basis for a port. Doing a "bare metal" port of Fuzix is probably possible but I think it would be extremely challenging and way beyond my skill set. However, this is why I suggest these would be great small group projects made up of people with diverse talents.
[Updated on: Sun, 01 May 2022 07:27] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9888 is a reply to message #9883] |
Sun, 01 May 2022 15:42 |
coredump
Messages: 33
Registered: January 2020
Location: Germany
|
Member |
|
|
Hi Sebastian,
68302: serial communication: You may want to check for handshake capability. On the 68360, You have a mode where
a CTS input is available.
But it stops after sending it's FIFO contents of 8 or 16 Bytes. That can be too much in some situations.
SRAM: I am using bs616lv8017 as 1MB. But there are some others, too. CY62167ELL-45ZXI is 2MB , last Year it
was available @ UTSOURCE for 4EUR each. But they are now @ 5,70...
OS: In 2000 I helped a friend porting µCLinux on a board (only a few minuscule hardware dependent things) with the 68VZ328
when both where quite new.
And it fitted very well into the 2MB of SDRAM. But I thought of MINIX when I assumed that 512KB are not very much.
An 68000 board with ethernet would allow for many interesting distractions. So it might be advisable to allow for a
single chip RAM and FLASH as large as possible while still being affordable (or outright cheap, like the SDRAM).
VZ: It's strictly 68000. Configuration of SDRAM Controller is two handful of suspicious bits. There's an application note regarding
SDRAm connection with sample code of initialization. It's much easier to understand configure than the SCC in the 68302 ;-)
And routing is as painless as a SRAM: It has more control lines but less address lines.Timing requirements are quite
relaxed at 33MHz: The CLK Line is point to point and can be made rather short. Data during read with CL=1 is valid
approx.15 ns before the next rising CLK edge. It can be routed for shortest connections without caring for equal line length.
I am using Micron's MT48LC16M16 A2-7E:D. It obviously didn't read it's own datasheet and can successfully be set to CL=1.
They where less than 2EUR each for 5pcs. a few Years ago. But You might want to have the newer G-Mask.
ENC624...: Indeed quite hard to get. But UTSOURCE, as usual, has some to sell. There's a (much less interesting- 8Bit Data Bus only)
variant ENC424J600-I/PT that even Reichelt is selling.
start address0: I was a bit 'short' there: since all the vectors for exceptions, interrupts etc. are located in the first KB of
Memory (fix in the 68000), every OS wants to change them, mandating RAM there. But since the Reset vectors are there too,
You certainly need ROM there directly after reset (or a good trick). But both 68302 an 68vz328 with their 'programmable'
chip select logic allow for simple configuration and reconfiguration.
RTC: I have tested one of the cheap china RTC-Modules with DS3231 on the VZ.
Interestingly, You can use the open collector 32kHz-output as a source for the VZ oscillator without too much additional jitter,
save the external chrystal an have the internal RTC of the VZ running synchronously with the battery backed external RTC.
Best Regards
Detlef
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9892 is a reply to message #9888] |
Mon, 02 May 2022 11:26 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
Hi
It occurred to me that if you're looking for an SBC design to run Fuzix that the Z180GDC would work. Z180 CPU is supported by Fuzix although it is not 16-bit as preferred in the original posting. Not sure if that's a hard requirement or a suggestion but if you're looking for an all-in-one SBC the Z180GDC might be a good choice. The Z180 is 8-bit but it is quite fast -- capable of 33+ MHz operation. I currently use mine at 18.432 MHz and it works fine.
I think this would be a great solution since the hardware already exists and has been debugged so there is little risk in leveraging the design. Once the graphical text console mode is working it will be capable of standalone operation not requiring a PC for console mode. Plus, it has IDE mass storage, RTC, dual serial ports, PS/2 keyboard & mouse, and a graphical system capable of using a VGA monitor.
Is the consensus hard-over on a 68K derivative or is there a willingness to accept other alternatives? If 68K derivative is a must then OK but if not there are other architectures running on MCUs which might be quite capable such as ARM or possibly even RISC-V. I suppose this gets to design objectives; is the goal to create a retrobrew type SBC or a modern computer running Fuzix? The original post seems be open to either approach although if you're looking for a 100x100mm PCB solution the MCU solution makes a lot of sense although it would almost certainly be an SMD design. Maybe that's an issue but maybe not. It just depends on what you are trying to do.
Best of luck, Thanks, Andrew Lynch
[Updated on: Mon, 02 May 2022 11:28] Report message to a moderator |
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9893 is a reply to message #9892] |
Mon, 02 May 2022 13:28 |
sebastian
Messages: 12
Registered: April 2017
|
Junior Member |
|
|
Thanks again, everybody. I hope I'm not forgetting anybody while trying to reply only to what was meant for me...
@robg:
Yes, I've looked at the Tiny68k already for inspiration, but the programmable logic used is a bit too involved for me. It's an elegant solution, but one I don't completely understand. The complexity in it is nicely hidden, but it's there. I could merely reproduce this, but I believe the educational value is higher if I'm at least close to seeing through the design. By the way, as well as this is done, it doesn't have a RTC.
@coredump
I didn't consider a handshake important, as the serial port is meant to be connected to a terminal (even if a modern one), which I expect to be ready to receive at any time by default, and sending single characters typed in via keyboard with such man-made delay that the SBC should have plenty of time to handle them. But maybe I missed comething.
Yes, SRAMs above 512kB are quickly getting more expensive, though they are available. The SDRAM is certainly more attractive in this light.
That's interesting about uCLinux, maybe a neglected option. Somewhere I've read getting Minix to run on custom hardware is pretty involved, and it's a relatively complex system despite its educational intention. Fuzix is probably a lot less convoluted (and of course less memory intensive). Large 16-bit flash chips are usually in TQFP packages, so sockets are hardly an option - getting any software into the newly assembled system may be a challenge.
Due to this, my original idea was using only a minimal loader in flash, and put the whole system on removable storage from which it would be copied to RAM - be it floppy disk, some IDE device, or - via external host controller - a 32 MB USB flash drive (those can actually be bought new, but I don't know if they really have the small block size such a system would require).
What you wrote about SDRAM sounds very optimistic, and definitely like an advantage of the VZ: RAM cheap and plenty. The MT48LC16M16 is such a common device, I could probably even salvage some from scrap. Haven't looked into the details, so I don't know what's different in the G mask, though.
Yes, I found the network chip at Reichelt. The 8-bit variant has the advantage of a package that's easier to solder. But maybe it's best to just break out the bus and make the network part a stackable add-on, leaving all options open. Two small boards are sometimes less expensive than a single big one. Currently I don't even know if it's problematic to connect 8-bit devices to a 16-bit bus or not.
The thing about start address 0 is understood. However, where Fuizx would best be loaded to, is still an unsolved question to me.
DS3231 or similar is a good option because of the wide operating voltage range. However, Seiko Epson RTCs often have an integrated crystal, which usually makes oscillator tuning unnecessary. I'm still undecided between these parts, but it's not a big thing to change that late in the design process.
Thanks for all the useful detail information! You're from Germany, too?
@lynchaj:
I had a look at the Z180GDC. It's pretty fascinating, but also pretty big in terms of size, and I don't know the cost of parts required. Indeed it would be a very worthwhile system to port Fuzix to, especially since it has basically everything, but it would be a waste not to use the graphics system (really good idea to use a RAMDAC for VGA output, btw), and the software work required may be well beyond my skills.
Admittedly, I'm a bit more partial to the Motorola side of things. Not because I think Zilog is inferior, not at all, but because I've got more personal experience with the former. I was aiming at a relatively small, beginner-friendly board (okay, surface mounted parts may be inevitable), not wanting to bite off more than I can chew. It's interesting you mentioned ARM or RISC-V. I know STM32 ARM MCUs from work, but I think the way they handle memory (Harvard architecture, code and data strictly separated) may not be an advantage to Fuzix, keeping code in flash and data in RAM. Both can't be expanded externally.
The RISC-V MCUs from GigaDevice may work in a similar fashion in this regard, and other RISC-V devices are still relatively uncommon.
Maybe I should clarify. What I have in mind is probably more on the retro side of things, though I'm willing to change my mind if someone tells me Fuzix on one of the larger STM32 derivatives or a GD32VF103 with a SD card attached would be a piece of cake, but I'm afraid this isn't the case. Someone would have done it already otherwise. Todays microcontrollers, made for small and specific tasks, may well be more complex than retro processors meant for building general-purpose computers, yet not equally suitable for all purposes. Correct me if I'm wrong.
So yes, I'm open to suggestions, but I'm biased in terms of keeping things simple, not only as in easy to build, but also in terms of understanding the inner workings. Maybe compromises are always necessary. In this regard, the MC68VZ328 could be okay even if more than originally planned, but anything significantly higher in complexity could mean starting a project I'd never finish. Your Z180GDC does have the advantage of being a finished design already, but I couldn't be of much use in regards to the Fuzix port, I fear.
Thank you very much for the good wishes, of course!
[Updated on: Mon, 02 May 2022 13:28] Report message to a moderator |
|
|
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9896 is a reply to message #9893] |
Mon, 02 May 2022 20:53 |
plasmo
Messages: 916
Registered: March 2017
Location: New Mexico, USA
|
Senior Member |
|
|
Sebastian,
Several points being discussion are interesting to me so I like to add a few comments.
Tiny68K rev2.1 does have RTC based on DS1302 with a supercapacitor as the backup power. The problem is the supercap is only good for few days and worse yet, the layout of the DS1302 is such that an active signal intruded on DS1302 exclusion zone causing the RTC to speeds up about 1 second per minute, The problem can be fixed with a new layout, but I'm dissatisfied with Tiny68K not expandable and its 16meg memory is really an overkill for 8MHz 68000 so I've two designs derived from Tiny68K that were not publicized but nevertheless documented in my homepage.
* T68KRC is Tiny68K with 2meg DRAM that plugs into RC2014 bus
* T68KMB is T68KRC with 3 RC2014 expansion bus
I believe some version of FUZIX has been ported to Tiny68K as well as T68KRC/T68KMB.
There is also an obscure 68K design, MB012, derived from Tiny68K but for MC68012 (I bet you've never heard of this part) that I did specifically for a few users. It is compatible with MC68000 PGA package.
How do you feel about FUZIX on 68020 and 68030?
DragonBall MC68EZ328 is something I'm interested in, mainly because I've foolishly acquired a large number of 68EZ328 but failed to read the fine prints and realized I've bought lots and lots of 68EZ328 in BGA package! I'm learning to solder BGA but in the meantime I do have a 68EZ328 development board using 100-pin TQFP. Sadly I don't have time for next few months to explore this project. Good thing about MC68EZ328 is it can boot with 8-bit EPROM and then switch to 16-bit RAM access so it can fit in 100x100mm PC board fairly easily.
Bill
PS, please feel free to use part or all the designs data for your use whether for personal uses of commercial uses.
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9897 is a reply to message #9895] |
Tue, 03 May 2022 05:07 |
lynchaj
Messages: 1080
Registered: June 2016
|
Senior Member |
|
|
Hi
Another update; there is Fuzix boot image for RC2014 with ROMWBW and Z80 so much of the work for porting to a Z180GDC hardware baseline largely done. What this would need is adjustments for Z180 CPU plus adaptations for the Z180GDC peripherals but since they are already supported in RomWBW I think that would be quite achievable.
https://www.fuzix.org/
https://www.fuzix.org/downloads/0.3/rc2014-0.3.ide.gz
Something to consider in your project is there are two learning curves to climb; one for developing the platform itself and another in porting Fuzix to the new platform. If you've not designed and built an SBC before you'll find getting the platform working properly is as big a challenge as porting the software and often requires multiple iterations to get it right. There is real benefit in reusing an existing platform that has already gone through the debug and fix cycle.
Thanks, Andrew Lynch
[Updated on: Tue, 03 May 2022 05:10] Report message to a moderator |
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9898 is a reply to message #9893] |
Tue, 03 May 2022 16:16 |
coredump
Messages: 33
Registered: January 2020
Location: Germany
|
Member |
|
|
Hi Sebastian,
sebastian wrote on Mon, 02 May 2022 22:28
I didn't consider a handshake important, as the serial port is meant to be connected to a terminal (even if a modern one), which I expect to be ready to receive at any time by default, and sending single characters typed in via keyboard with such man-made delay that the SBC should have plenty of time to handle them. But maybe I missed comething.
Indeed, the way You are describing it,hardware handshake does not come into mind immediately.
Serial communication programms like minicom allow for sending plain .txt files over the line, too.
You might want to use it to get a file system image during development into the device to burn it into the small
program flash (like the MX29lv128D, that is around 1,25EUR @ UTSOURCE). Transfering 15MB this way is painful if You have to reduce
the baud rate to avoid overflow.
An other point are these nice modules that try to build a serial communicaton via bluetooth. Since the VZ has 2 UARTs and runs from 3V
someone might find it interesting to connect them. They usually have rather small buffers an when they try to send the data, they might become
quite unhappy with a communications partner that does not propperly handle handshake.
Sooner or later You might come into the situation to connect something to the UART where hardware handshake is the straightforward and simple solution.
It's just routing two lines...
sebastian wrote on Mon, 02 May 2022 22:28
That's interesting about uCLinux, maybe a neglected option. Somewhere I've read getting Minix to run on custom hardware is pretty involved, and it's a relatively complex system despite its educational intention.
According to Alan Cox MMUless found it's way into the mainstream linux kernel. So uCLinux might be a bit stale. But never the less quite interesting to play with.
In the late 80's, when the atari st version of MINIX was available, I managed to get it running on my homebrew 60000 computer.
So since I could do, You can do most probably using the left hand only.
Because this computer had only 256KB of RAM, I could have a shell, maybe a second one, than the memory was exhausted.
Since those days, MINIX became more fat. The original bourne like shell consumed less than 50kB. Since than, ash and bash where ported.
I bet those will not fit into 50kB ;)
So You can see the reason for me to recommend having much more than 512KB of RAM.
sebastian wrote on Mon, 02 May 2022 22:28 Large 16-bit flash chips are usually in TQFP packages, so sockets are hardly an option - getting any software into the newly assembled system may be a challenge.
Due to this, my original idea was using only a minimal loader in flash, and put the whole system on removable storage from which it would be copied to RAM - be it floppy disk, some IDE device, or - via external host controller - a 32 MB USB flash drive (those can actually be bought new, but I don't know if they really have the small block size such a system would require).
Up to the MX29lv160, You can have them in SOP44 with 1,27mm pin spacing, if You like this more.
But for sure You can solder the FLASH on the board and use the bootstrap mode of the VZ. Simply spoken, it communicates via UART, allows for writing into memory
(first the internal configuration registers to set up memory, than programs into the activated memory) and starting (these) programs.
So loading a small program that would flash a payload into soldered flash is a possibility.
And all those small test programs to check hardware can be loaded into memory, too. Without flashing. You will like it...
sebastian wrote on Mon, 02 May 2022 22:28
Yes, I found the network chip at Reichelt. The 8-bit variant has the advantage of a package that's easier to solder. But maybe it's best to just break out the bus and make the network part a stackable add-on, leaving all options open. Two small boards are sometimes less expensive than a single big one. Currently I don't even know if it's problematic to connect 8-bit devices to a 16-bit bus or not.
It unfortunately has the disadvantage of having a multiplexed address/data bus. Using a simple solution to connect it disallows to use it's 24KB buffer
as a program memory. Since the 16bit variant has the same pin spacing as the VZ processor and the CS8900A I assumed it would be ok. I only came with the 8bit
chip because the 16bit is much harder to get. It would come at some cost.
BTW here is the errata: https://ww1.microchip.com/downloads/en/DeviceDoc/ENC424J600- ENC624J600-Errata-DS80000477B.pdf
Not too bad.
sebastian wrote on Mon, 02 May 2022 22:28
The thing about start address 0 is understood. However, where Fuizx would best be loaded to, is still an unsolved question to me.
DS3231 or similar is a good option because of the wide operating voltage range. However, Seiko Epson RTCs often have an integrated crystal, which usually makes oscillator tuning unnecessary. I'm still undecided between these parts, but it's not a big thing to change that late in the design process.
You're from Germany, too?
You can find the loader in the fuzix repository. I seem to recall it will end up finally at $400++.
DS3231 comes with an internal quartz, ist temperature compensated for higher accuracy over the temperature range and has a aging register that
allows simple tuning by software, if ever necessary. There is also a variant with internal backed up ram. But paralleling an eeprom on the IIC-lines might be as useful. A parallel RTC is something I would avoid. The SDRAM eg. has (just from my memory) a risetime around 1ns at the data lines.
You may want to keep the data lines as short as possible. Any additional chip will load the lines with its capacity and will make them longer.
The VZ has 2 SPI interfaces and quite a lot of gpios for peripherals. So there is litte need to hook up more than the VZ, flash, SDRAM, ETHERNET and a bus driver for IDE on the data bus.
Yes, I'm from Germany.
Finally, btw., the VZ has a lcd controller included that can do 640 x 480 with monochrome panels. Not very useful the way it is, but one can build on it.
And adding a ps/2 keyboard isn't a very hard task (mainly consisting of the gpio lines, interrupt capable for the clock line,
and a bus switch for 'level shifting' that allows bidirectional communication abd the pull ups). So these lines could be brought to an expansion connector to
allow having fun with it later on.
Best Regards
Detlef
|
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9906 is a reply to message #9899] |
Sun, 08 May 2022 15:23 |
 |
will
Messages: 213
Registered: October 2015
|
Senior Member |
|
|
Hi Sebastian
I am also very interested in a computer that lies on the spectrum somewhere between vintage 8-bit CP/M micro and full-fat modern Linux machine.
I would like hardware that is simple enough for someone to understand the circuit schematic fully, and which a person with a little soldering experience can assemble by hand. I'd like a couple of UARTs (one for the console), 8MB or more of RAM, ethernet, some sort of mass storage (SD cards over SPI work very well in my experience), and an expansion bus that you can easily design and build your own cards for.
I would like software which is simple enough for someone with a grasp of basic operating systems concepts to understand, with a POSIX-like API (the "gold standard" in many ways), and which is capable enough to be used for "real" tasks like running a text editor, compiler, python, SSH. I don't want it to be such a huge thing that you can't even identify all the software involved (so, simpler than modern GNU/Linux). Much like the hardware I want something that the hobbyist or student could understand well enough to extend. Importantly I want the system to be self-hosting; all the software for the machine should build on the machine itself. Bonus points if you can run KiCAD and design the PCBs :)
I think in practical terms this means we need a machine with a 32-bit address space. 16-bit address spaces are just too small. On 16-bit Fuzix machines we don't have a working fsck or C compiler. We can probably engage brain and get fsck working, but a useful modern C compiler is a much bigger challenge that I don't think we're going to solve -- the path of least resistance is "get a bigger machine" and it's hard to justify why you wouldn't (other than the intellectual challenge of making it work in 16 bits!).
I think the PIC32MZ is an interesting option, it's a 32-bit MIPS with a lot of onboard peripherals. It has 512KB internal SRAM but I think it unfortunately lacks a way to add external RAM. There are at least a couple of interesting unix ports to it already -- LiteBSD and RetroBSD.
Another interesting option is the KISS-68030 or another fast 68K with MMU. This ticks almost all the boxes on the hardware side for me. I've ported modern Linux to KISS-68030 and it runs well, including working GCC compiler etc ... but the standard userspace is very slow! A contemporary Linux userspace assumes you have plenty of CPU power at your disposal so you end up with complex shell scripts that take a minute or more to run, etc. I don't mind waiting for the compiler to do its magic but I do mind waiting ten minutes for the machine to run a complex hierarchy of scripts that ultimately just mount a filesystem and show me a login prompt. I'm not familiar with NetBSD but I think it might be a good candidate for a "lighter" unix port to this hardware.
If I had a fairy godmother I'd ask her for a RISC-V general purpose CPU with MMU, in a hand-solderable package, and with a simple external bus interface for memory and peripherals. I expect most RISC-V CPUs we see will be either microcontrollers with no external memory, or desktop processors with complex bus interfaces and BGA packages -- so polar opposites with nothing in the hobbyist sweet spot (and it is, admittedly, a vanishingly tiny market so I'm not surprised). Maybe the answer is to use an FPGA module to contain the CPU ... but my problem with FPGAs is I very quickly end up stuffing basically everything into the FPGA, which isn't the fun hardware soldering project I wanted.
Will
[Updated on: Sun, 08 May 2022 15:39] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9910 is a reply to message #9909] |
Tue, 10 May 2022 10:21 |
sebastian
Messages: 12
Registered: April 2017
|
Junior Member |
|
|
Sorry for replying late, I hope you all don't mind. Lots of stuff to reply to...
@lynchaj:
Maybe Z180 is easier to get to work indeed. You have a point in using through-hole components, it's of course a preferrable assembly experience. I'm lucky to have access to a good microscope at work, though, so I can at least check if everything is soldered when using SMD parts, which are sometimes hard to avoid.
In regards to Fuzix on Z180 systems more generally, I think it has been done for the SC130 by Stephen C. Cousins, but this is of course a lot less complex than the Z180GDC.
You're right about the learning curves. It would be easier to start with working hardware. But I'm far more of a hardware guy than a software guy, so the software is the difficult part for me, and I prefer to have full understanding of the hardware before working on the software.
@plasmo:
The Tiny68k rev2.1 looks interesting. The CPLD used is not easily available here in the package type used, but maybe it can be bought from a broker or through ebay from China.
I really don't know about 68020 & 68030... of course their performance is superior, but doesn't that come with even more added complexity? Keeping things simple means more chance of finishing anything.
I wonder if any work for the MC68VZ328 could also benefit the MC68EZ328... Good luck with the BGA stuff, some people have done that in a pizza oven, but it may require patience.
@coredump:
Handshake makes perfect sense if files are to be sent via terminal, that's true.
I didn't even know about MMUless in mainstream Linux. For anything like this, 512k are quickly exhausted. That makes SDRAM-based systems more interesting, although it goes beyond the scope of Fuzix. Your confidence in my skills is flattering, but I'm not a software professional, so I might not be easily able to replicate your results.
Soldering the network chip will be manageable. But I think the network option might be best done as an add-on still.
Looking at Fuzix source code will probably be necessary to see how this works.
Thank you about the warning against a parallel RTC on data lines shared with SDRAM.This sounds troublesome anyway, I hope other chips like the flash are not bothered by interference. Maybe even adding IDE to this would mean inviting trouble.
The LCD controller will be highly useful, a big selling point. I've got SP24V001 panels in the parts drawer, the 4-bit interface looks like a perfect fit. Makes for an 80 characters, 25 lines text display easily, I think. PS/2, no idea if it can be run interrupt driven, of if polling the keyboard will consume much time, but if we have a display, having a keyboard interface is only logical.
@nealcrook:
This is good advice, but while I think getting a CPU simulator to work is within my possibilities, simulation of the integrated peripherals would be necessary, and probably really complicated. Might take more than a year, so the price for debugging convenience in terms of time is hefty.
@will:
Looks like what you're imagining could be fulfilled with the MC68VZ328, but it remains to be seen if this is easy enough to solder, and the bus could be too sensitive to break out. On the other hand, the Tiny68k has that much ram, but does it have multiple UARTs?
|
|
|
|
|
|
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9914 is a reply to message #9910] |
Wed, 11 May 2022 08:29 |
coredump
Messages: 33
Registered: January 2020
Location: Germany
|
Member |
|
|
Hi Sebastian,
I'm not a professional programmer, too. You might have to change time against
experience and knowlegde but will most probably gain some of the later. So just feel encouraged, not flattered.
Since more and more new ideas for different processors quickly turn up, what about recalling/setting/refining Your requirements/goals in a short list?
From what I did understand from Your posts, You want to do it yourself.
And You want to do the FUZIX port yourself.
Since writing lists is quite cumbersome I also want to present a short and rather minimalistic way out:
-50 x 50 mm² pcb 4layer
- the unavoidable VZ
- 16bit flash in ssop44 (--> fits nicely on the bottom side under the VZ, easy to route)
- the mentioned SDRAM alt a smaller SDRAM (64Mbit, 128 MBit) alt. 256kx16 static. Reichelt has eg. IS61WV25616BLL
- arduino µSDCARDshield, 3,3v on one SPI of VZ (quite uncool but very simple)
- header for arduino ENc28j60 ethernet shield on other SPI of VZ
- 1 or 2 UART-headers à la tiny68k. May use USB 5V to power the card.
- regulator xx1117-class for 5V-> 3v3
Those being the essentials. Depending on space left on pcb:
- maybe arduino RTC-shield
- maybe reset switch
- maybe INT7 switch
- maybe simple IDE interface
This would be rather low budged and could be made (as an estimation) in 2 month or less.
Since You will do it, it includes full understandig of the hardware.
So around 10 month left to joyfully port the OS to Your hardware.
SP24V001: Are You shure You want to attach this? From the datasheet I found, it's 8bit parallel and split screen.
Best Regards
Detlef
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9916 is a reply to message #9914] |
Thu, 12 May 2022 17:02 |
|
will
Messages: 213
Registered: October 2015
|
Senior Member |
|
|
In my mind, Fuzix is primarily targeting machines with limited memory, typically a 16-bit address spaces with some form of banking. The main aim of Fuzix is to have a portable and capable OS and utilities that will fit in the cramped space available on 16-bit micros.
So while you can run it on a 32-bit machine, the ideal "SBC specifically for Fuzix" is probably a 16-bit machine with a 256KB or more of banked memory. All of the Fuzix ports I worked on were such machines: the Z80 Zeta2 (512KB), the Z180 Mark4 (512KB) and P112 (1MB), and my pre-Fuzix port of UZI-180 to Z80 and the sdcc compiler for my socz80 (8MB) FPGA project.
Alan has developed a really clever build system that makes adding new architectures and ports simple. On the architectures it supports you can port it to a new machine relatively easily if you're happy writing a bit of assembler. Adding another architecture is a more work but possible if you can find a workable C compiler. If you're not sure how to do something you can always look at another machine and see how they did it.
Fuzix doesn't expect much from the machine. You need mass storage, a UART or video display/keyboard, a timer interrupt, and you probably want (but don't strictly require) banked memory, at least on 16-bit machines.
Just pick an architecture you like, find or make a machine, and port it! "A unix in every pot"!
@lynchaj: I am interested in a PIC32MZ based machine. A 200MHz MIPS machine you can build yourself sounds great!
I am confident we could get Fuzix running on a PIC32MZ dev board. The EBI SRAM would be nice to have, but it's probably not necessary since 512KB is loads for Fuzix and even if it's not there's an SD card for swapping. It would be interesting port to a 32-bit machine.
Do you like the DA chips because you want the additional on-chip memory, or because you want graphics generated from the SBC? I'm used to thinking of SBCs with serial consoles, but graphics/keyboard could be fun. The PIC32MZ has a USB host for a keyboard. I wonder what hardware we need to add to drive an HDMI output.
I've ordered a Diligent 410-302 dev board, but more to play with LiteBSD than to port Fuzix. I'd also like to assess if I can get a useful C compiler to run on the PIC32MZ. The dev board only has the 512KB on-chip RAM. The KISS-68030 can run linux and GCC but it has 256MB DRAM, is even a PIC32MZ with the max 64.5MB SRAM enough for GCC? I also have a strong suspicion that I can't build GCC for LiteBSD!
I'm going to look at SmallerC. Maybe there's another MIPS C compiler I should consider?
I went shopping and the availability of the PIC32MZ chips seems to be very poor (hardly unusual at the moment).
|
|
|
|
| Re: Building a SBC specifically for use with Fuzix [message #9917 is a reply to message #9916] |
Sat, 14 May 2022 07:17 |
|
will
Messages: 213
Registered: October 2015
|
Senior Member |
|
|
A quick update: I've received the Digilent "Wi-Fire" PIC32MZ development board. I've managed to build the LiteBSD kernel and userspace and get it running on this board. It works pretty well! It seems to find the WiFi chip on the board but I don't think the driver is actually usable yet. LiteBSD being based on 4.4BSD, it ships with the Portable C Compiler ... sort of. The userspace contains "cc" and "cpp" but not "ccomp" so it will preprocess your program but then fails to translate C to assembler. It doesn't seem to try to build ccomp. I need to investigate why.
The FT2232H chip on the board is connected to both a UART and to the JTAG TAP on the PIC32MZ. The UART console works fine, very straightforward. I've written a config for OpenOCD to talk to the JTAG port, and I can detect and talk to the MIPS EJTAG, but I think I need to write another config for OpenOCD to explain how the PIC32MZ is laid out internally -- it only supports the PIC32MX at the moment. With JTAG working we could run GDB to remotely debug the machine. I think we can also program the PIC32MZ's internal flash over JTAG, which will hopefully be faster than using the STK500v2 compatible UART bootloader that came flashed onto the board.
Was surprisingly hard to get this all to work. I feel I'm cobbling things together -- part of a toolchain from over here, another part from over there, reading schematics and datasheets to figure out how OpenOCD should talk to it all, basically I'm surprised there isn't more good documentation out there. This does not feel like a popular platform!
I'm going to work on getting the compiler to build and generate MIPS code, verify that swapping works, and try to get remote GDB and flash programming to work through OpenOCD.
I'm conscious that I am hijacking the "SBC specifically for use with Fuzix" thread to talk about non-Fuzix stuff. If anyone wants me to start a separate thread please do say!
4.4BSD-Lite build 0 compiled 2022-05-13
btg@badhorse:LiteBSD/sys/compile/WIFIRE.pic32
cpu: PIC32MZ2048EFG100 rev A1, 200 MHz
oscillator: system PLL div 1:6 mult x50
cache: 16/4 kbytes
real mem = 512 kbytes
avail mem = 340 kbytes
using 18 buffers containing 73728 bytes of memory
spi1 at pins sdi=RF1/sdo=RC1/sck=RD1
spi2 at pins sdi=RF0/sdo=RD11/sck=RG6
spi3 at pins sdi=RB10/sdo=RC4/sck=RB14
spi4 at pins sdi=RF5/sdo=RG0/sck=RD10
uart1 at pins rx=RD14/tx=RD15, interrupts 112/113/114
uart4 at pins rx=RF2/tx=RF8, interrupts 170/171/172, console
sd0 at port spi3, pin cs=RC3
gpio0 at portA, pins -i---ii-iiiiiiii
gpio1 at portB, pins i---i-iiiiiiiiii
gpio2 at portC, pins iiii---------i--
gpio3 at portD, pins --ii------iiii-i
gpio4 at portE, pins ------iiiiiiiiii
gpio5 at portF, pins --ii--------i---
gpio6 at portG, pins oiii--iii-------
mrf0 at port spi4, pins cs=RD9, irq=RA15, reset=RF4, hibernate=RG1
mrf0: MRF24WG version 31.c, MAC address 00:1e:c0:21:77:c0
bpf: mrf0 attached
sd0: function groups 1/1/1/1/1/3, max current 200 mA
sd0: type SDHC, size 7563264 kbytes, speed 50 Mbit/sec
sd0a: partition type b7, sector 2, size 204800 kbytes
sd0b: partition type b8, sector 409602, size 32768 kbytes
sd0c: partition type b7, sector 475138, size 102400 kbytes
bpf: sl0 attached
bpf: lo0 attached
WARNING: preposterous clock chip time -- CHECK AND RESET THE DATE!
starting file system checks.
/dev/rsd0a: 2325 files, 16674 blocks used, 33541 free
/dev/rsd0a: MARKING FILE SYSTEM CLEAN
starting network
clearing /tmp
standard daemons: update cron.
Fri May 13 12:09:54 PDT 2022
4.4BSD-Lite (bsd.net) (console)
login: _
[Updated on: Sat, 14 May 2022 07:26] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Current Time: Wed Mar 19 01:55:43 PDT 2025
Total time taken to generate the page: 0.00766 seconds
|
RetroBrew Computers Forum
Members
Search
Help
Login
Home
