RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

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 Go to previous messageGo to next message
etchedpixels is currently offline  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(Wink 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 Go to previous messageGo to next message
zamp is currently offline  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 #3800 is a reply to message #3796] Mon, 20 November 2017 21:06 Go to previous messageGo to next message
computerdoc is currently offline  computerdoc
Messages: 130
Registered: October 2015
Senior Member

Hi Bill,
Hmm, some TTL Serial to USB modules have straight through wiring and others have crossed wiring. How interesting?!? Well, this is the TTL Serial to MicroUSB module I'm using. If I have done this correctly, you should see a red circuit board with a MicroUSB connector, 6 pin male header on the other end. A jumper for 5v or 3.3v VCC and 9 empty holes for headers on each side of the board.
https://ssli.ebayimg.com/images/g/jk8AAOSwrklVMjIp/s-l1600.jpg
The connections are currently as follows.
PC Tiny68K
TX RX
RX TX
RTS CTS
CTS RTS
GND GND
I have tried with no RTS/CTS connections which of course didn't show any data at all.
I tried RTS - RTS and CTS - CTS and no data in this configuration.
I tried RTS - CTS and CTS - RTS and I get data, but no kermit activity.
I'm not really sure what to try next.
  • Attachment: s-l500.jpg
    (Size: 38.19KB, Downloaded 408 times)


Kip Koon
computerdoc at sc dot rr dot com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3801 is a reply to message #3800] Mon, 20 November 2017 21:14 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Kip,
Were you able to put a voltmeter on the pins of interests and run through test 1, 2, and 3? What are the results? I'm try to figure out whether it is Tiny68K, seria-to-USB adapter, or PC.
Bill
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3802 is a reply to message #3801] Tue, 21 November 2017 05:37 Go to previous messageGo to next message
computerdoc is currently offline  computerdoc
Messages: 130
Registered: October 2015
Senior Member

Hi Bill,
I have not been able to do the tests yet. I hope to be able to do the tests later on today. Somehow, I missed that particular message.
I WILL read it today and let you know the results of the tests. Thanks for asking.


Kip Koon
computerdoc at sc dot rr dot com
http://www.cocopedia.com/wiki/index.php/User:Computerdoc
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 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
etchedpixels wrote on Mon, 20 November 2017 14:53
Some 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 #3813 is a reply to message #3810] Wed, 22 November 2017 05:20 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
Unix came from the PDP11 world so it was originally built for a processor which had at least minimal MMU features. One result of that is they picked a stunningly elegant way of creating new processes where you make a system call and it creates an exact copy of the existing process and returns to both (one with a return code 0, the other with the id of the child). On a machine without memory protection or banking you can;t have two processes at the same address.

The 16bit machines have memory banking to deal with the address space limits so this works niicely, the 8086 has segment registers for the job, but the 32bit machines don't. It also doesn't bite my tiny 68K setup because it only has enough room to keep the OS and one program in memory and swaps between them via disk, but it does bite for anything bigger.

There are two ways to deal with it. Linux on MMUless simply doesn't provide fork(Wink only a variant where the child runs until it has finished and the parent then gets the memory back (possibly mangled). That works because almost all uses of fork(Wink are followed by starting a different program (at a different address) at which point the parent can run again/ Minix swaps the memory around between the correctt address and a copy according to which one of the parent/child are running. That is slower obviously but given the child almost always runs another process was almost always fine. In fact kermit was about the only Minix program that used fork(Wink and kept both processes around and busy!

Once I have my benches and tools back I do want to get the MMUless 68000 support sorted out. In theory it's not that complicated to do the memory exchanging one, and I have a couple of other designs to play with including the one used by MAPUX on the Amiga.

Some day I also want to build a system (probably in FPGA) with the proposed 'minimal MMU' that almsot made the Atari ST.

http://www.dadhacker.com/blog/?p=1383


I've got an ENC28J60 on my SocZ80 board and I did indeed have 'fun' getting it to work because it was incredibly fussy about things like delays after the last SPI clock before deasserting CS and it doesn't error such things but ignores some groups of register writes and hands back the wrong register value when you upset it. It does work now though - even in CP/M, not that it's very useful there.

Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3814 is a reply to message #3813] Wed, 22 November 2017 06:52 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
The article linked talked about replacing upper address with constant values which is exactly what I have in mind. It is a modified memory map logic in CPLD that has an n-bit register providing the upper address values except a couple specific address ranges that are not translated. This simple scheme will have fixed common memory areas and 2**n banked memory controlled by the n-bit register. The common memory (which includes memory mapped I/O) is supervisor level while the banked memory is user level. The banked memory that's not active are invisible therefore protected. Is this is all we needed to get UNIX into 68000?
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3815 is a reply to message #3814] Wed, 22 November 2017 10:27 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
Well you can fudge it with memory copies and the like but for a properly running 'classic; Unix like OS yes it''s all your need and ideally it throws an exception when you access stuff you shouldn't. Some of the early Unix machines like the original Sun workstation with a 68000 CPU worked this way (although the Sun 1 was very quickly replaced by a 68010). In theory your existing board has enough on it to run MMUless Linux.

You don't actually nee da 68010 except for doing full on virtual memory, the compiler can be told to generate a non-meaningful reference to memory just below where it wants the stack to extend to and the OS can catch the exception knowing it doesn't need to fix it up. Or indeed on some early systems the compiler would generate calls to a stack check in each function entry - slightly costlier than hardware traps but not a lot.

Dealing with power of 2 aligned memory is a bit of a pain in the backside but there is an allocation algorithm designed for it (buddy allocator)

Alan
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #3816 is a reply to message #3815] Wed, 22 November 2017 13:29 Go to previous messageGo to next message
zamp is currently offline  zamp
Messages: 19
Registered: April 2017
Location: Finger Lakes, NY, USA
Junior Member
BMoW has built a 68008 that runs uClinux called 68 Katy. The only thing that Tiny68K seems to be missing to run uClinux is a periodic timer interrupt on /IPL2. Complete info on the Katy 68 hardware (including /IPL2 requirements) and software (including uCLinux port and complete toolchain for cross-compiling uClinux) can be found at https://www.bigmessowires.com/68-katy/.

There is a nice article on how uClinux works without an MMU at: https://www.eetimes.com/document.asp?doc_id=1200904

I don't know whether or not I'm interested in Linux on the Tiny68K. It would allow a lot more code to run, but the OS might be more complex than I personally want to get into.


Ron

[Updated on: Wed, 22 November 2017 15:41]

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 Go to previous messageGo to next message
plasmo is currently offline  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 Go to previous messageGo to next message
zamp is currently offline  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 #3828 is a reply to message #3820] Thu, 23 November 2017 10:23 Go to previous messageGo to next message
mikemac is currently offline  mikemac
Messages: 249
Registered: March 2017
Senior Member
A successful port is a shell/login prompt.


Mike
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4023 is a reply to message #3828] Wed, 27 December 2017 13:47 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
The FTDI cable I purchased was set up for the pinout in the following article:
ESP8266 Tutorial

This seems to be fairly standard for the TTL USB-Serial cables that I've found.

EDIT: FTDI's doc on their USB cables here confirms this pinout.


--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!

[Updated on: Wed, 27 December 2017 14:11]

Report message to a moderator

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 Go to previous messageGo to next message
plasmo is currently offline  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 Go to previous messageGo to next message
UhClem is currently offline  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.


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 Go to previous messageGo to next message
plasmo is currently offline  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 Go to previous messageGo to next message
UhClem is currently offline  UhClem
Messages: 19
Registered: November 2015
Junior Member
plasmo wrote on Mon, 08 January 2018 18:06
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.


Why would the CF ground change when its output drivers are attempting to source current from Vcc?


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 Go to previous messageGo to next message
plasmo is currently offline  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 Go to previous messageGo to next message
UhClem is currently offline  UhClem
Messages: 19
Registered: November 2015
Junior Member
plasmo wrote on Mon, 08 January 2018 21:22
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.


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.


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 Go to previous messageGo to next message
plasmo is currently offline  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.
index.php?t=getfile&id=768&private=0
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 Go to previous messageGo to next message
plasmo is currently offline  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 #4157 is a reply to message #3702] Fri, 26 January 2018 09:38 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
A few things on these USB-Serial converters:
-Some of the older Prolific units have no driver support in newer versions of Windows. See http://prolificusa.com/pl-2303hx-drivers/
-There were a lot of counterfeit Prolific chips around at one point causing problems - http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=155& pcid=41
-Counterfeit FTDI products are also a problem and FTDI's driver now detects some of these and inserts characters into the data stream

-I've never used the CP2102 so no experience there.

Something to consider when troubleshooting user problems with USB converters.
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 Go to previous messageGo to next message
lowen is currently offline  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 #4183 is a reply to message #4160] Sun, 28 January 2018 10:44 Go to previous messageGo to next message
mikemac is currently offline  mikemac
Messages: 249
Registered: March 2017
Senior Member
Soldering wires to the bottom of BGAs now? I don't know whether I should be more impressed by your devotion to your small form factor designs or your stash of all sorts of 68Ks! Smile

https://hackaday.com/2018/01/28/the-tiniest-working-68k-system/



Mike
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4184 is a reply to message #4183] Sun, 28 January 2018 12:38 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Surprised Ha ha, I guess the staffs of Hackaday look around for unusual projects and blog about it. Perhaps the over-the-top project title (Melting the balls off the DragonBall) caught his attention. Not my first time soldering to BGA. I built a complete PowerPC MPC555 system soldering to MPC555 BGA (BGA is the only package format available for MPC555). That was probably 15-20 years ago and I was younger and better at soldering. I think I still have it somewhere, need to dig it out and post that on Hackaday.

The soldering skills were developed when pc boards were expensive and took long time to fabricate. With cheap board in 10cm*10cm format and 1 week turn-around, I think that skill set is going to evaporate. I'm getting old, so that skill will soon evaporate anyway. Oh well.
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4189 is a reply to message #4184] Mon, 29 January 2018 08:46 Go to previous messageGo to next message
lowen is currently offline  lowen
Messages: 226
Registered: August 2016
Location: Western NC USA
Senior Member
Cool. Reminds me of dead-bug prototyping.... (DIPs in legs-up configuration, glued to a board or even a piece of metal).

On the 16MHz tack, I bought a 16MHz 68HC000P16 a couple of weeks ago, and it runs great at 8, but I thought it would be cool to try it out higher. Also note that the 68000P12F is actually rated 16MHz. It is a lot easier to find PLCC and PGA 16Hz parts, that is for sure. The part I received didn't have any of the telltale signs of counterfeits (I've received counterfeit Z80's before, remarked Z80H's that said they were 20MHz Z84C00's) but i remains to be seen if it will run at 16.

With the Z80's there is a test for the CMOS Z84C00 versus the NMOS Z80H that can be run by software; is there anything similar for the 68000 versus the 68HC000?

The first 16MHz DIP64 part I bought was actually an SPDIP64 with 0.07 inch pin-spacing versus regular DIP64 with .1 inch spacing. So if you see a sale for a 'DIP61 68HC00016' make sure you get the 'P' package instead of the 'N' package.

PLCC is nicer.


--
Bughlt: Sckmud
Shut her down Scotty, she's sucking mud again!
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4190 is a reply to message #4189] Mon, 29 January 2018 10:15 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
Learned something new every day. P12F is indeed 16.67Mhz part designation. so I misspoke about not able to find 16MHz DIP64 package. I noticed there are several P12F on eBay, although I'm always leary about paying extra for the fastest part. This is where you find counterfeit parts--slower part re-labelled as faster, more expensive parts.

With a 16MHz part you may be able to run it at 20MHz, but the DRAM access time (which is already marginal at 16MHz) may not support 20MHz at zero wait state. It is simple to add a wait state, but the performance may actually lower when going from 16 to 20MHz by adding a wait state to memory access.

I'm not aware of a test to distinguish 68HC000 from plain old 68000. HC is the low power CMOS version.

Is the SPDIP64 really 0.700inch? I read on Motorola 68000 datasheet a 0.600 inch version of DIP64, but couldn't find a 0.700 inch version. I made a mistake in version 0 of the Tiny68K with 0.600in DIP64 footprint:
https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=152&goto=2942&#msg_2942
That board might actually work with the SPDIP64 package.
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 Go to previous messageGo to next message
lowen is currently offline  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.

index.php?t=getfile&id=805&private=0


--
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 #4192 is a reply to message #4191] Mon, 29 January 2018 10:38 Go to previous messageGo to next message
norwestrzh is currently offline  norwestrzh
Messages: 190
Registered: November 2015
Senior Member
>> .... the 0.07-spcing SPDIPs (original Hitachi HD64180 is the same package).

Yes, but be careful. I believe the Z180 (HD64180) in this SPDIP package has one less address pin than the PLCC version, so it can only address half of the memory that the PLCC version can.

Roger
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4193 is a reply to message #4191] Mon, 29 January 2018 11:36 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
lowen wrote on Mon, 29 January 2018 11:24
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.



I read your description too quickly and leap to my own conclusion. Sad So this is the same weird pin spacing as Yamaha V9959. I think there actually is a socket for it, but it is crazy expensive.

I discovered I do have a number of PLCC 68000 (keeping on finding stuffs in my messy garage! Wink and re-layout the Tiny68K pc board. It runs faster and I have board space for other things.

[Updated on: Mon, 29 January 2018 11:37]

Report message to a moderator

Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4194 is a reply to message #4193] Mon, 29 January 2018 11:45 Go to previous messageGo to next message
pbirkel is currently offline  pbirkel
Messages: 61
Registered: October 2015
Member
plasmo wrote on Mon, 29 January 2018 11:36
lowen wrote on Mon, 29 January 2018 11:24
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.


I read your description too quickly and leap to my own conclusion. Sad So this is the same weird pin spacing as Yamaha V9959. I think there actually is a socket for it, but it is crazy expensive.


Although I have no first-hand experience I've read elsewhere that the trick to handling this situation "reasonably" is to rotate the chip by 45 degrees and then bend outwards alternating pins. You'll notice that they then all fall on 0.1" centers -- or close enough to fudge :->. Of course the pins bent outwards will not have as much leg-socket contact, but I've read that using machine-pin sip-socket pieces works OK. Still a pain, of course. But more affordable than crazy-expensive!
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 Go to previous messageGo to next message
lowen is currently offline  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. Smile


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 Go to previous messageGo to next message
mikesmith is currently offline  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 Go to previous messageGo to next message
plasmo is currently offline  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 #4432 is a reply to message #4431] Thu, 08 March 2018 07:02 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
Some 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)

For TCP/IP there are several free 'off the shelf' stacks including uIP (which is what Fuzix uses on 8bit systems), and LWIP. LWIP would probably be appropriate for a 68K system and it's very easy to integrate into anything as it mainly needs a timer, memory allocators and a hardware device driver. Linux has its own TCP/IP stack of course.

You don't need ethernet for TCP/IP - it runs over anything including serial and carrier pigeon.

Alan
Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K [message #4433 is a reply to message #4432] Thu, 08 March 2018 07:18 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
@mikesmith: If you look at https://github.com/EtchedPixels/Virtual68 that's got a CF/ATA emulation library I wrote that should be reasonably close to the full specification and which I use in various emulators I've written or hacked on.

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 Go to previous messageGo to next message
plasmo is currently offline  plasmo
Messages: 866
Registered: March 2017
Location: New Mexico, USA
Senior Member
etchedpixels wrote on Thu, 08 March 2018 08:02
Some 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. Laughing 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! Shocked it is on Wikipedia "IP over Avian Carriers"... Laughing Shocked

-------------------------
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 #4435 is a reply to message #4434] Thu, 08 March 2018 07:51 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
Yes I was in Bergen with the crazy Norwegians when they actually proved it worked.

For my retro stuff I actually mostly use serial and the SLIP or CSLIP protocol for internet. It's a very small in code and data requirements and a lot easier than trying to retrofit ethernet to old hardware.

[Updated on: Thu, 08 March 2018 07:51]

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 Go to previous messageGo to previous message
mikesmith is currently offline  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...Wink

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...Wink 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.Wink https://en.wikipedia.org/wiki/UEXT

The '030 redesign also sounds pretty interesting. You should share so that we can have opinions about it. Cool

= Mike
Previous Topic: Another 8085 Single Board Computer SBC-85
Next Topic: CTC/SIO Baud Rate Generation


Current Time: Fri Mar 29 04:59:29 PDT 2024

Total time taken to generate the page: 0.01072 seconds