Home » RBC Forums » General Discussion » Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K (68000, CP/M-68K, 100mm x 100mm pcb)
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3798 is a reply to message #3797] |
Mon, 20 November 2017 13:53 |
etchedpixels
Messages: 333 Registered: October 2015
|
Senior Member |
|
|
Some comments:
I believe Sozobon C output should be fairly easy to tweak for if not compatible with CP/M 68K, as it targets TOS which is what CP/M 68K got turned into for Atari. It's got full source code and while it's a K&R compiler it's quite passable and even self hosting.
Fuzix for 68K is an ongoing project - it'll boot on a minimal 68K platform but doesn't yet know how to handle anything but boards with very limited RAM and swap. Multiple processes in memory gets exciting because there is no banking and no MMU that can be used to make fork( work properly, thus some memory copyiing is required to make it all hang together. It has minimal TCP/IP support using uIP, which is targetted more at the 8bit end. For 68000 it would probably want to use wIP or similar given enough memory. For networking you really want ethernet or similar but there are SPI bus ethernet chips and I've used those with micros before successfully. In some ways the Soneplex board is more interesting for this as Bill kindly broke out the SPI interface pins on the CF card add on board. Rgiht now however most of my benches and stuff are in storage until I get the room redecorated.
Gcc 68000 is a bit variable, some variants of the compiler had a nasty habit of outputting non 68000 instructions when told not to, or hiding them in the support libraries. I had to fix one library generation problem in gcc 6 to get Fuzix to behave. The code it generates is however vastly better than anything else I've seen from the other compilers.
Other possible OS's: Don't overlook Minix 1.6 (gcc cross compilable kernel tree available on the internet). That would need a bit of work for the disk and I/O drivers, although the ones needed would be vastly simpler than the ones it has for Atari as there is no console, no DMA driven SCSI like hard disk, no floppy controller of crawly horrors etc to deal with. And if you can get the kernel to go then the existing file system will do the rest. On the TOS front there is EmuTOS which is an open re-implementation of Atari TOS that has been ported to various systems and provides an environment akin to the Atari ST in text mode. It'll also run GEM although someone would have to build a backplane and graphics card for that to be useful.
Alan
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3799 is a reply to message #3798] |
Mon, 20 November 2017 18:52 |
zamp
Messages: 19 Registered: April 2017 Location: Finger Lakes, NY, USA
|
Junior Member |
|
|
Alan - Thanks for the compiler and OS suggestions. Sozobon looks pretty interesting. Personally, I'd want a native toolchain on CP/M-68K itself, so gcc isn't something I'd pursue for the Tiny68K. If someone else wants to cross-compile their code, that's fine, but I'm not interested in that other than maybe bootstrapping a toolchain onto CP/M-68K.
I'm going to think about a direction I want to go for a bit. Meanwhile, I'll try to get some little tools up on CP/M-68K.
Ron
|
|
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3810 is a reply to message #3798] |
Tue, 21 November 2017 18:21 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
etchedpixels wrote on Mon, 20 November 2017 14:53Some comments:
Fuzix for 68K is an ongoing project - it'll boot on a minimal 68K platform but doesn't yet know how to handle anything but boards with very limited RAM and swap. Multiple processes in memory gets exciting because there is no banking and no MMU that can be used to make fork() work properly, thus some memory copyiing is required to make it all hang together. It has minimal TCP/IP support using uIP, which is targetted more at the 8bit end. For 68000 it would probably want to use wIP or similar given enough memory. For networking you really want ethernet or similar but there are SPI bus ethernet chips and I've used those with micros before successfully. In some ways the Soneplex board is more interesting for this as Bill kindly broke out the SPI interface pins on the CF card add on board. Rgiht now however most of my benches and stuff are in storage until I get the room redecorated.
Alan,
I'm not much of a software person to know why banked memory works better than flat memory implementing fork(). In fact, never use fork() in my limited software experience. However, creating banked memory in 68000 memory map is probably not hard (haven't done it, just thinking it out loud). Given there already is a 16 meg SIMM, it can be divided into a common 8-meg memory and 8 1-meg banked memory. A 3-bit register selects which 1-meg memory is the active bank memory, the other 7 1-meg memory are invisible. At any moment there will only be 9 megabyte of memory, 8 meg of common plus 1 meg of banked memory. Is this the kind of banked memory configuration you like to have?
When it comes to TCP/IP, the ENC28J60 module is probably the simplest and cheapest solution. It does need a decent SPI interface. I'm interested in how well the 68302 on the repurposed Soneplex board works with the SPI-to-Ethernet.
Bill
[Updated on: Tue, 21 November 2017 18:22] Report message to a moderator
|
|
|
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3820 is a reply to message #3816] |
Wed, 22 November 2017 17:54 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
That's pretty inspiring. I remember this discussion on our forum about it,
https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=43&start=0&
I visited it, but didn't see the detailed documentations then. Looking at the video, it only takes 6 seconds to boot up uCLinux with the 12MHz 68008. That's pretty fast. He is doing all that with 1/2meg of ROM, 1/2 meg of RAM, and no disk. Tiny68K at 12MHz is about twice as fast. Imagine what 16meg of memory backed with large CF can do. However, I know so little about Linux that I wouldn't know what a 'successful port' looks like, but then I know very little about CP/M 6 months ago, either. Hmmm, very interesting...
Tiny68K does have a timer associated with 68681. The boot monitor programs it to generate an interrupt every 10mS. The circulating segments on the 7-segment display is driven by by the timer interrupt service routine. My BIOS shuts off all interrupts that's why the 7-segment display is not changing when CP/M68K is running.
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3823 is a reply to message #3820] |
Wed, 22 November 2017 19:30 |
zamp
Messages: 19 Registered: April 2017 Location: Finger Lakes, NY, USA
|
Junior Member |
|
|
Now I see the timer. :-) I was looking in the wrong place, on the schematics, not in Tiny68kbug where the DUART initialization and interrupt service routine are. And I see you have it running at 100Hz (same rate as BMoW's timer) while Tiny68kbug is running. And if I'm reading the DUART datasheet correctly, you can even change the timer interval without effecting the async interfaces, at least for some common baud rates.
Ron
|
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4050 is a reply to message #4023] |
Mon, 08 January 2018 11:04 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
An update on the CF interface issue of rev1 Tiny68K: After tried about 10 different brands of CF cards including one that computerdoc kindly loaned to me, I believe the problem is due to ground bounce of fast CF driving a 16-bit high-capacitance data bus. This is a CF read problem and is data dependent such that reading data with all 1's (0xFFFF) can cause a glitch on the CF read control line. Because CF data register is a FIFO, a glitch on the read line will flush the current data and output the next data. A faster CF is more sensitive to glitch. This is why data with value of 0xFFFF dropped out of the sector data stream. This is not a common problem, of the 10 or so brands of CF I tried, only 3-4 brand had this problem and one Tiny68K board is particularly susceptible to this problem. The newer, faster, higher density CF is more likely to have this problem than the older, slower, and lower density ones.
A number of factors contributed to this issue: 2-layer pcb without power/ground layers, direct connect of CF to 68000 data bus, and 5V system. I don't want to change the 5V supply or go to the costly multi-layer pcb, so the solution was focus on the interface between CF and CPU and test the fixes on the one Tiny68K that's particularly susceptible. There are 3 separate fixes, each incrementally reduces the magnitude of the ground bounce. They are presented from the most effective to the least effective.
1. Pull up half of the data bus with a SIP 10K resistor pack. With the pull-up, the data bus is precharged to half low and half high so a data pattern of 0xFFFF only drive 8 data lines from low to high instead of 16. The magnitude of ground bounce is reduced by half. This is also an easy fix, just solder a SIP resistor pack to the 68000DIP and tie the common pin to a 5V point nearby. (see 2nd picture)
2. Terminate the CF read strobe (nIORD) with 100 ohm series resistor and a 100pF capacitor. The added network has a RC time constant of 10nS that should suppress fast glitch without unduly slowing down the read access.
3. Isolate the CF data bus with 100 ohm resistors. This effectively slow down the CF bus driver thus reduce the magnitude of the ground bounce.
Having said all that, your Tiny68K (rev 1 pcb) may not have any issue with the CF. If you do, try an older, lower density CF card and solder a 10K SIP resistor pack to the back of the board should fix it. If the problem is still there, please let me know. We can arrange an exchange.
The 3 fixes are implemented in rev 2 of Tiny68K. (see third picture) I've built and tested 8 of them and they are completely trouble-free so far (knock on wood).
[Updated on: Mon, 08 January 2018 11:10] Report message to a moderator
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4051 is a reply to message #4050] |
Mon, 08 January 2018 16:36 |
UhClem
Messages: 19 Registered: November 2015
|
Junior Member |
|
|
I suspect that the problem is actually due to power. If it were ground bounce I would expect it to occur when the card switched its data outputs from high to low. Not low to high.
The first problem is that 5V power comes in via a barrel connector. The result is an impedance on the power supply that is considerably higher than what you would have if there were a three terminal regulator on board. Which translates to more noise on the power rails.
Then there is power distribution. In an ideal world the CF card would get a dedicated power and ground connection to the voltage regulator. By doing this any power glitches generated in the CF card (or other parts) are terminated by the low output impedance of the regulator before they can get to other parts.
Power traces need to be sized appropriately and what you have seems a little thin. The big loop that the ground connection to pin 2 of the IDE connection takes also bugs me. Besides the extra voltage drop you have a nice big ground loop. (also known as an antenna)
There really should be a nice big tank capacitor next to that barrel connector. 100uF minimum. Also keep the wire to the power supply as short as possible and make sure that the supply has a nice low output impedance. Even better would be a supply with remote sense capability.
David Schultz
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4053 is a reply to message #4051] |
Mon, 08 January 2018 18:06 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
In the process of debugging this problem, I've added liberal amount of bypass (0.1uF) & filter capacitors (10uF) all over the board and CF adapter card without changing the problem condition. Adding additional ground wires from CPLD (source of control signals) and CF adapter can marginally improve the problem. When examining the data captured compare to the reference data, data with value of 0xFFFF and sometime 0xEFFF/FEFF/FFEF/FFFE are missing.
My explanation is this: When data bus is at rest, it drifts toward ground; reading 0xFFFF means CF drivers are pushing all data lines from ground toward 5V; the capacitive loading of the data lines will resist rapid change so instead, the weakly connected CF adapter ground will spike below the reference ground. When the adapter's ground spiked below 1.5V with respect to the reference ground, the CF read line (active low nIORD which is generated by the CPLD) becomes effectively above 1.5V with respect to the CF ground. That rising glitch on the CF read line causes the FIFO to flush the 0xFFFF and read the next word. The faster, newer brands of CF are able to drive the data bus faster, generating greater ground spike than the slower, older brands of CF.
If the explanation is correct, then connect a capacitor between CF read line and CF adapter ground should reduce the magnitude of the spike. It does, and adding an isolation resistor helps even more. This is fix #2. However, as you've observed, the fix #2 is not ideal because adapter ground is not nearby, thus the fly wire from capacitor to the pin 2 of the CF adapter. The inductance of the fly ground wire reduces the effectiveness of the RC network.
Fix #1 works because instead of all data lines drifting to ground, half of them are pulled up to 5V, so when CF read 0xFFFF, only 8 lines are driven from ground to 5V thus the magnitude of ground spike is cut in half.
Fix #3 place 100 ohms isolation resistors between CF data bus and the processor data bus thus reducing the instantaneous current of CF driver and therefore the magnitude of the resulting ground spike.
Rev2 pcb implemented all 3 fixes without adding more bypass/filter caps or changing power distribution. I've tried the various brands of CF that had caused problems with rev1 pcb without encountered any problems.
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4055 is a reply to message #4053] |
Mon, 08 January 2018 19:01 |
UhClem
Messages: 19 Registered: November 2015
|
Junior Member |
|
|
plasmo wrote on Mon, 08 January 2018 18:06My explanation is this: When data bus is at rest, it drifts toward ground; reading 0xFFFF means CF drivers are pushing all data lines from ground toward 5V; the capacitive loading of the data lines will resist rapid change so instead, the weakly connected CF adapter ground will spike below the reference ground.
Why would the CF ground change when its output drivers are attempting to source current from Vcc?
David Schultz
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4056 is a reply to message #4055] |
Mon, 08 January 2018 21:22 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
That's a good question. Since CF draws its power from board's VCC, a good argument can be made that when all 16 fast data bus drivers want to raise 16 capacitive loads from ground to VCC, the CF's internal 5V rail will collapse. No doubt the CF's internal voltage may droop somewhat, but CF has its own power capacitors whose capacitance is orders of magnitude greater than the data line's load capacitance, so while there is a large instantaneous current, the resulting voltage drop across the CF's power rail is small. If voltage across CF's supply does not change much and we know the capacitively loaded lines can't change instantaneously, then voltages need to develop either on the driver side or the ground return to satisfy Kirchhoff's voltage law. There are 16 parallel drivers but much fewer ground returns so the bulk of voltage differences will developed across the ground return, thus the negative ground spike.
EDIT: I really don't know whether the majority of voltage differential will develop across the ground return. Certainly a significant voltage will develop across the drains and sources of FET drivers, but there are 16 of them driving in parallel so the effective impedance is low. If more than 1.5V voltage differential developed in the ground return, it is enough to upset the FIFO.
[Updated on: Mon, 08 January 2018 21:56] Report message to a moderator
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4058 is a reply to message #4056] |
Tue, 09 January 2018 16:10 |
UhClem
Messages: 19 Registered: November 2015
|
Junior Member |
|
|
plasmo wrote on Mon, 08 January 2018 21:22If voltage across CF's supply does not change much and we know the capacitively loaded lines can't change instantaneously, then voltages need to develop either on the driver side or the ground return to satisfy Kirchhoff's voltage law.
Please describe the loop used in your Kirchhoff's voltage law analysis. Without knowing that, I have no idea what you think is happening.
Newer CF cards that support the faster ATA modes will have output drivers capable of higher edge speeds. Perhaps fast enough so that your layout could cause trouble with reflections and coupling to other signals. The pullups would act as poor transmission line terminations and help a little. Series resistors on the data bus would slow the edge speeds and make the PCB layout less of a problem.
David Schultz
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4059 is a reply to message #4058] |
Tue, 09 January 2018 20:20 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
I've retired a number of years now and no longer have access to the high-end layout tools that can extract the layout topology and device parameters to build an accurate SPICE model of the network in question, so there is quite a bit of arm waving here. Diagram below shows the notional network.
The dash line is the boundary between CF adapter and the main pc board. When driving 0xFFFF, all 16 drivers on CF are turned on and current flows from CF power source to charge up the load capacitors on the main pc board and return via the ground traces. The voltage drop is divided between Vd (FET drivers), Vl (capacitive loads), and Vg (ground returns). Vl can't change instantaneously, 16 drivers have relatively low inductance compare to the few ground return lines, so a significant voltage is developed across the ground return. I acknowledge that FET driver need voltage differential to operate and lacking good model for the driver, I can only guess the magnitude of the ground spike.
Inserting resistors in data line limits the current and therefore reduces the voltage across the ground return lines. 100 ohms probably also match the line impedance (more arm waving here) and help with reflection as well. The pull up resistors are 10K so negligible as signal terminations. Its main purpose is to precharge half of the load capacitors so only half of the load capacitors are driven from ground to 5V, thus halving the current.
I certainly agree with you that having 16 modern drivers with fast edge rate driving into un-terminated, not controlled impedance 2-layer board is problematic. The saving grace is the relatively slow components on the main pc board are not responsive to the sharp signal spikes and reflections. The pc board is also small, 10cm x 10cm, thus less susceptible to reflection. The one device that is affected is the same modern CF which will react to the fast spike caused by its own drivers. That's the problem I'm trying to solve.
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4148 is a reply to message #4059] |
Thu, 25 January 2018 20:36 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
Interfacing with the serial port seems to be the most troublesome problem with the users of the Tiny68K.
I've tried 3 brands of USB-to-serial adapters:
1. Prolific PL2303 USB to DB9 (RS232 voltage level)
2. CP2102 USB to TTL
3. FT232R USB to TTL
The Prolific adapter is my standard serial port adapter and worked with my PC for many years. I did all my Tiny68K development with the Prolific adapter. It works.
I purchased CP2102 USB-to-serial adapter here: https://www.ebay.com/itm/6Pin-USB-2-0-toTTL-UART-Module-Seri al-Converter-CP2102-STC-Replace-Ft232-ModuleH/173031824816 I build a kludge board to bring the CTS, RTS, Rx, Tx signals to the correct pins. This setup works well with Tiny68K
The FT232R USB-to-serial adapter is the same as the one pictured here: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;amp ;th=222&goto=3800&#msg_3800 I also build a kludge board to bring the signals to the correct pins. The board can handle transmit & receive, but the RTS/CTS handshake does not work, The terminal software I used are TeraTerm, HyperTerminal, and RealTerm. I'm running Windows Vista which is no longer supported with the latest version of FTDI drivers, so I'm using the older version of driver. It is possible the old version of driver does not support RTS/CTS handshake, but that seems unlikely.
I like to hear Tiny68K user's experiences with the serial adapters. What brand of serial adapters are you using? What terminal programs and what operating systems?
[Updated on: Thu, 25 January 2018 20:39] Report message to a moderator
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4160 is a reply to message #4157] |
Fri, 26 January 2018 10:38 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
Plasom, I'm using an FTDI USB cable with CentOS 7 Linux with the in-kernel FTDI driver, and RTS/CTS is working fine. If it's useful for you, here's some detail:
[16236.423101] usb 3-3: new full-speed USB device number 4 using xhci_hcd
[16236.592972] usb 3-3: New USB device found, idVendor=0403, idProduct=6001
[16236.592996] usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[16236.593000] usb 3-3: Product: FT232R USB UART
[16236.593003] usb 3-3: Manufacturer: FTDI
[16236.593006] usb 3-3: SerialNumber: AH069DFT
[16237.642317] usbcore: registered new interface driver ftdi_sio
[16237.642355] usbserial: USB Serial support registered for FTDI USB Serial Device
[16237.642707] ftdi_sio 3-3:1.0: FTDI USB Serial Device converter detected
[16237.642772] usb 3-3: Detected FT232RL
[16237.643139] usb 3-3: FTDI USB Serial Device converter now attached to ttyUSB1
[lowen@dhcp-pool101 ~]$ sudo lsusb -v -s 3:4
Bus 003 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 FT232R USB UART
iSerial 3 AH069DFT
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2 FT232R USB UART
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
[lowen@dhcp-pool101 ~]$
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
|
|
|
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4191 is a reply to message #4190] |
Mon, 29 January 2018 10:24 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
The SPDIP has a pin-to-pin spacing of 0.07inch; the package width is 0.6 inches. I'd rather work with a PLCC than the 0.07-spcing SPDIPs (original Hitachi HD64180 is the same package).
EDIT: Two pics attached showing the differences between the 'P' package and the 'N' package. 10% resized version inline; hi-res attached.
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
[Updated on: Mon, 29 January 2018 10:41] Report message to a moderator
|
|
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4197 is a reply to message #4194] |
Mon, 29 January 2018 12:04 |
|
lowen
Messages: 226 Registered: August 2016 Location: Western NC USA
|
Senior Member |
|
|
While this is way off-topic, the reason the 45 degree trick works is because a right triangle with the two angles being 45 degrees has a side ratio of 1:1:1.414 (square root of two). If the hypotenuse is 1, then the other two sides at 0.707, which is close enough for this trick to work. Sorry for the trig tangent.... (rimshot).
I have a PLCC 68000 processor here, a MC68HC000FN12F, which is also stamped '16 MHZ.'
Update: received a good working DIP64 MC68000P12F, and have a 16MHz TTL can here on another board... will try some time this coming week.
Reply to a slightly different topic:
zamp wrote on Sun, 19 November 2017 18:09
An hour or so into the CP/M-68K port, rzsz is so far looking like I'll get it working. I've got most of rz|rb|rx reworked into rxyz -x|-y|-z. I'm not having to #ifdef out much code. And so far I've not run into any long names.
Zamp, how did this port of rzsz go?
--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
[Updated on: Sat, 03 February 2018 13:19] Report message to a moderator
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4430 is a reply to message #4197] |
Wed, 07 March 2018 23:25 |
mikesmith
Messages: 80 Registered: March 2018
|
Member |
|
|
Another Tiny68K owner checking in here; just wanted to share a few things.
I've put together a simulator for the Tiny68K using the Musashi core bridged to Python. Musashi handles the CPU emulation, the bridge handles memory emulation, and then device emulation is implemented in Python (making writing and testing device models somewhat simpler).
Currently it emulates the 68681 and CF well enough to boot CP/M and run MicroEmacs with configurable tracing. Next on the list (but lower priority) is to implement the I2C state machine well enough to model the EEPROM and DS1203. I expect that it would be straightforward enough to model some of the other Tiny family as well. Speed is pretty good, certainly very usable.
Code is here: https://github.com/John-Titor/py68k
A couple other things I've been tinkering with:
uCLinux bFLT to CPM .REL converter (mostly done), this is one of the missing links in building CP/M-68K executables with GCC.
Porting EmuTOS to Tiny68K. Should not be too hard to copy one of the headless ColdFire targets and shuffle things around, the IDE support looks basic enough to work with the CF card, then there's just the DUART to deal with. Would be interesting to know if anyone else has already started on this...
On the subject of C compilers for the 68k, there is also VBCC: http://sun.hasenbraten.de/vbcc/ It's a bit newer (C89) than Sozobon and probably generates better code...
[Updated on: Wed, 07 March 2018 23:28] Report message to a moderator
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4431 is a reply to message #4430] |
Thu, 08 March 2018 05:28 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
Welcome aboard, Mike!
Thank you for your contribution. These areas are well ahead of what I'm capable of and is something I like to learn. I know Tiny68K is capable of EmuTOS and even uClinux, but I don't know how to get there. Exploring these capabilities is important for the evolution of the Tinyxxx. I have redesigned the Tiny68K to add Ethernet and other peripherals, but the complexity of TCP/IP stack has kept me away. I'm also thinking frequently about redesigning the Tiny030 (68030). It can handle more modern operating systems, but also needs more modern peripheral such as Ethernet. How do you emulate something complex like the Ethernet?
Edit, I know I've posted a picture of the redesigned TIny68K somewhere. Here it is, but Ethernet and the USB-to-FIFO module are not present.
https://www.retrobrewcomputers.org/forum/index.php?t=getfile &id=798&
[Updated on: Thu, 08 March 2018 05:33] Report message to a moderator
|
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4434 is a reply to message #4432] |
Thu, 08 March 2018 07:28 |
plasmo
Messages: 866 Registered: March 2017 Location: New Mexico, USA
|
Senior Member |
|
|
etchedpixels wrote on Thu, 08 March 2018 08:02Some of the ethernet cards are actually very easy to emulate. They may well be very complex inside but their observed behaviour is really simple. Another useful trick with i2c and spi is to attach the emulated i2c/spi bus to a real USB to i2c/spi adapter and then you can run the emulation with real hardware. I've actually got low level Z80 CP/M code for one of the cards somewhere (testing tool that sends raw packets, receives one, configures the chip)
Then the actual communication data packet from the hardware talks back to the PC, a genuine hardware-in-the-loop emulation. Love it!
etchedpixels wrote on Thu, 08 March 2018 08:02
You don't need ethernet for TCP/IP - it runs over anything including serial and carrier pigeon.
It is a packetize with scatter & gather, so indeed you can send them via carrier pigeons. I shouldn't laugh, with you Brit's love of pigeons and proclivity for the wacky, somebody may have done it already. Heck, it may well be an annual event.
Wait, I better look this up...WHAT! it is on Wikipedia "IP over Avian Carriers"...
-------------------------
OT alert! but the wiki article on "IP over Avian Carrier" is truly hilarious (to the geeks, my wife didn't see the humor at all). A great and very funny quote:
IPoAC may achieve bandwidth peaks of orders of magnitude more than the Internet when used with multiple avian carriers in rural areas. For example: If 16 homing pigeons are given eight 512 GB SD cards each, and take an hour to reach their destination, the throughput of the transfer would be 145.6 Gbit/s, excluding transfer to and from the SD cards.
[Updated on: Thu, 08 March 2018 07:41] Report message to a moderator
|
|
|
|
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4436 is a reply to message #4435] |
Thu, 08 March 2018 19:35 |
mikesmith
Messages: 80 Registered: March 2018
|
Member |
|
|
@alan - thanks for the Virtual68 pointer. I had missed it in my survey of assorted m68k emulators; if you don't mind, I may steal some functionality from the IDE code there when my current atrocity falls short.
@bill - with the proliferation of virtual machines, there are pretty standard ways of bridging Ethernet packets from an emulated Ethernet adapter into the host OS networking stack, either by creating a new private virtual network, or by effectively sharing the host's network interface. As Alan notes, what you're emulating has to conform to the contract that software has with hardware, not with the actual implementation, which is frequently license for cheating a lot.
With regards to the TCP stack; you don't want anything to do with it if you can possibly avoid it. Depending on your objective, pick one and treat it like a black box. If you pick an existing OS, most will have a solution already (or someone you can badger about it). Which Ethernet MAC did you choose? (He asks with some trepidation...
On the subject of peripherals, I know you're out of macrocells, but if you're considering a bigger CPLD I have a couple of suggestions (this is a lie, I have lots of suggestions, but I will try to keep myself restrained):
- A SPI controller with a reasonable number (4-6) of chip selects (the '681 GPOs would be fine... would enable a lot of peripheral options. A FIFO would be nice, but not essential.
- If you haven't already, consider the UEXT interface connector. You already have a spare UART and I2C, and in conjunction with a SPI interface it would give you a ton of peripheral options (display, keyboard, WiFi, USB, etc. https://en.wikipedia.org/wiki/UEXT
The '030 redesign also sounds pretty interesting. You should share so that we can have opinions about it.
= Mike
|
|
|
Current Time: Fri Mar 29 04:59:29 PDT 2024
Total time taken to generate the page: 0.01072 seconds
|