Subject: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 01 Nov 2017 04:02:56 GMT View Forum Message <> Reply to Message This is a branch off "Plasmo's 68k pathfinder projects" https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=152&start=0&

Since the rev 1 of Tiny68K is reasonably matured, I like to start a new topic dedicated to this design and its derivatives. There is a wiki page for Tiny68K: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k

A brief highlight of features: * 68000 CPU with a nominal clock of 8MHz * Entire 68000 address space is filled with a 16-meg SIMM72 DRAM except for I/O devices located at the top 32K bytes. * 68681 dual UART. Port A is dedicate to console at 38400, N81, CTS/RTS handshake. Port B is available for other uses. * IDE44 interface to CompactFlash * Two serial EEPROM, 24C256. Software may boot from either serial EEPROM depending on one jumper select. The second EEPROM is writable in-situ. * A 7-segment display for status indication. plasmo wrote on Fri, 27 October 2017 23:09

* I encountered a curious bug on "pip" command: when I tried to concatenate multiple files using the command format: pip file1.txt=file2.txt,file3.txt I get the error message:

Exception $03 at user address $0001B1BA. Aborted. pip works fine otherwise. This error occurs in simulation as well, so it may be a bug in pip command or corrupted distribution disk. * Beside the strange bug in "pip", most software work fine except gkermit. It just hung. * Creating a new CF disk is kludgy. I'm not smart enough to have a general solution that reads CP/M68K image (created with cpmtools) on FAT directory and creates a CP/M CF disk. So my solution right now is using cpmtools to create a CP/M68k image, converting it to srecord and serially loading into the RAMdrive location on Tiny68K. With the disk image loaded and CP/M running, I can then copy the files in the RAMdrive into CF. This works well, except loading 2 megabyte disk image into RAM at 38.4K baud takes about 30 minutes. Only need to do this once to create a new CF disk, but it is slow nevertheless. * Still working on an utility that will copy first 32K byte of memory into the 2nd serial flash. With this utility a new boot serial flash can be created thus allowing boot software update without the need of an external programmer. * I did all my tests with SanDisk brand of CF which work well. I do have one Transcend brand of CF that read/write FAT16 files correctly on PC but does not read/write CP/M68k files correctly on Tiny68K. I'm concerned that Tiny68K hardware/software may only work with a subset of CF. I'm ordering a batch of Transcend CF and see if I can figure out what the problems may be. Bill

Page 1 of 82 ---- Generated from RetroBrew Computers Forum Most of the issues I was concerned about have been successfully resolved: * The problem with concatenating files using PIP is due to a bug in the BIOS, so is the issue with file upload/download with Kermit. They are both working properly now. * I'm glad I tried other brands of CF because the original setup time was too short. I added more wait states to CF access so it now has appropriate amount of setup time, access time & hold time. It should works reliably for different brands of CF (keep my fingers crossed!. * I now have an utility software that can copy first 32K byte of data in memory to the 2nd serial EEPROM. The utility software needs more polishing, but the hardware is all there to allow in-situ programming of the serial EEPROM. * The creation of new CF disk is still slow. I don't have a Linux box and rawrite32 does not work on my Windows Vista machine. It takes about 30 minutes to serially upload the CP/M68K distribution files. Only need to do that once and when the new CF disk is created, everything works quickly and correctly afterward. * I did all the development and testings with 8MHz CPU clock, but I tried 12MHz clock on two boards and they appear to work.

I'm close to shipping out the boards. What need to be done are: * Tweak the boot monitor so it will display various steps on the 7-segment display as it boots up. If the monitor failed to boot, it may show where it failed. * Documentation! Never enough but more is better.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 01 Nov 2017 04:28:18 GMT View Forum Message <> Reply to Message computerdoc wrote on Tue, 31 October 2017 02:12Hi Bill, I would love to use the PLCC version of the 68681. I have only found an Advance Information datasheet for the 68681. Although it has a PLCC version of the MC68681FN, I would feel better about creating an Eagle part with the finalized Datasheet. Do you have a finalized MC68681FN Datasheet? Attached is all I can find so far. I've tried several sites. If you or anyone can find a better datasheet, I would be most grateful.

Kip, Here are more comments about your design: * For the 40-pin IDE connector, you may want to add a jumper between pin 20 and VCC. Some IDE-to-CF adapter derives the 5V power from pin 20. * Jumper options around 24C256 are not quite right. There need to be a jumper option for each 24C256 from pin 1 to ground. The 24C256 with pin 1 to ground is the boot device. Jumper to pin 7 of 24C256 is for write protect. Only one 24C256 need to be write protected. * You need a 10-pin programming header (2x5) for Altera EPM7128 * SIMM72 draws large current spikes and needs filter capacitors near the connector. Two 10uF caps located at each end of the connector should be enough. * Reset button and voltage monitor do not go directly to 68000. It goes to EPM7128 (signal name nPORST). State machine in EPM7128 holds 68000 in reset until content of the boot 24C256 is

Page 2 of 82 ---- Generated from RetroBrew Computers Forum loaded into DRAM then it releases the reset to 68000. * Pin out of PLCC44 in Advance Info for 68681 is correct. * Look at the footprint of the EPM7128. longer finger pads are better for hand soldering..

If you like me to help your bring up the board, send me 2 bare boards. I'll solder down the EPM7128 on both and return one board back to you. I'll populate the 2nd board and see if I can bring it up. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 05 Nov 2017 03:38:04 GMT View Forum Message <> Reply to Message OK, I'm ready to ship Tiny68K as assembled boards or kits. I assembled 5 boards to check out the design. All 5 boards work with 12MHz CPU clock even though the 68000 is a 10-MHz part. So it appeared to have good design margins. I'll ship the two assembled boards with 12MHz oscillator. For the kits, I will still ship with 8MHz oscillator just to be safe. I'll PM people who have expressed interested in Tiny68K requesting their shipping address and payment details.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 06 Nov 2017 14:13:18 GMT View Forum Message <> Reply to Message I received payments for 6 Tiny68K boards in the last 36 hours. Thank you all! All boards are assembled and programmed; the fully assembled boards are also tested with various diagnostics at 12MHz. I will start shipping them out today and be done by tomorrow. I will PM the USA buyers with tracking numbers. For the international buyers I will send you the Custom number, but USPS does not track the Custom number. Photos below are what you should expect in the package. First two photos are that of a fully assembled & tested board. They are shipped with SIMM72 installed, all you need is apply 5V to the 2.5mm jack and null serial cable with CTS/RTS handshake. The next two photos are what a kit #2 looks like. Discrete capacitors, leaded resistors, and hardware are in separate bags; the 44-pin CF adapter is directly from the factory; and active components are on an anti-static foam. Sockets are for 68681, 68000, and two serial EEPROM. The serial EEPROM (2 pcs) are pre-programmed with identical monitor software. The last photo is the partially assembled board with surface mount components soldered and EPM7128 programmed; the SIMM72 memory has been tested. I'm currently working on a more detailed assembly instruction, the thing I learned and watched out for during the assembly of the last 7 boards. However, this is my design and I'm an experienced assembler (please excuse my gross self indulgence) so if I missed some details please ask for clarifications. I'll get back to you in 24 hours. I'll also add instruction on how to create the 1st CF disk and a listing of the monitor software in the

Page 3 of 82 ---- Generated from RetroBrew Computers Forum serial EEPROM. That's all for now, have fun with it!

------Update on 11:20am Boards are all shipped. The domestic packages should arrive this Thursday. I don't have an estimated date of arrival for international shipment. ------

File Attachments 1) assembled_Tiny68K_front.jpg, downloaded 1131 times 2) assembled_Tiny68K_back.jpg, downloaded 481 times 3) kit2parts.jpg, downloaded 569 times 4) partial assembly with SIMM72DRAM.jpg, downloaded 502 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by computerdoc on Tue, 07 Nov 2017 06:02:44 GMT View Forum Message <> Reply to Message Hi Bill, Thank you SOOOOO much! You ARE the MAN!

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 08 Nov 2017 21:49:39 GMT View Forum Message <> Reply to Message The packages should arrive tonight and tomorrow. My phone & internet service went down yesterday morning while I was working on the Tiny68K wiki page. The repairman won't even be here until tomorrow morning. I still can surf the web through the phone, but getting files from my computer and upload to the wiki is more complicated than I can manage. The instruction on how to assemble kit #2 is in pretty good shape, https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k:tiny68k_kit2 but I need to complete the work on how to create a new CF disk. So bear with me for a couple days while I get the internet sorted.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Fri, 10 Nov 2017 00:55:59 GMT View Forum Message <> Reply to Message Package arrived right on schedule, in good shape. I have a couple of questions.

No values given for resistors. From the photos, I get R3-R9 220, R16-R18 4k7, R10 10k, and R14

Page 4 of 82 ---- Generated from RetroBrew Computers Forum 1k7 (?? a little hard to see that one).

Any guidance on the 7 segment display? -- size?, CC or CA? Can't read the chip numbers on the serial EEPROMs. CF adapter available on eBay??

Oh, and that reminds me. I'd be interested in getting whatever is necessary to hook up a CF to the Soneplex. Do you have any plans to produce a PCB or adapter to fit to it??

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Fri, 10 Nov 2017 06:13:22 GMT View Forum Message <> Reply to Message Roger, The part list from the Tiny68K wiki page should answer most of your question: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k:rev1partlist

I have produced an IDE daughterboard for the soneplex MPU board as shown here: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=201&goto=3625&#msg_3625 I need to work on a wiki page for it as well. Bare board is $1.50 ($1 shipping). populated/tested board is $8 ($3 shipping)

My internet is still down. I used the public library computer to update the page on creating a new CF disk for Tiny68K, but it is not finished: https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k:create_new_cf

Life without Internet is a struggle. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Fri, 10 Nov 2017 22:03:25 GMT View Forum Message <> Reply to Message My kit #2 showed up a couple of days ago and looks very nice and extremely well packed. Thank you very much, Bill.

I'll probably build it up this weekend and I'm looking forward to loading CP/M.

I've read through https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k:create_new_cf and it all makes sense. I think that everything needed is there, except for writeBoot.s68 . That's the only file I can't find.

Page 5 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 11 Nov 2017 02:24:08 GMT View Forum Message <> Reply to Message I'm glad you've received the package in good shape. My internet connection is restored now. I updated the "create new CF" page with link to writeBoot and t68kram. Corrected a few typos. It is ready for use.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Mon, 13 Nov 2017 14:58:30 GMT View Forum Message <> Reply to Message I built up the Tiny68K kit #2 and installed all chips and SIMM, but did not yet install a CF card. It was about 1:30AM by the time I hooked up a Prolific USB to serial cable (a Raspberry Pi console cable). That USB to serial cable has only Rcv and Xmt, not CTS or RTS. Tonight, when I have more time and I am more awake, I'll set up something else with CTS and RTS, but I was hoping with just that that I'd at least see the Tiny68kbug greeting, even if I didn't have flow control for input to the monitor.

I configured my terminal emulator for 38,400 8N1 and powered up the Tiny68K. The LED immediately displayed 8 and did not show any animation of and LED segments. Pressing reset didn't change the display at all. I get output from the first console port, but it's random junk that is intermittently displayed.

I'll try again with CTS and RTS connected, but from my reading of T68kbug.X68 I don't expect to see anything different. I think I need to do some debugging. Do these seem reasonable first steps?

Check for bent pins (I checked last night, but it was pretty late). Check 5V on board. Swap U5 and U7 in case one of them didn't get programmed. Check clock with oscilloscope.

I think that Ben pre-programmed the Altera EPM7128SQC100 and the two AT24C256PC. I've got an Altera USB blaster and a CH341A programmer, so I supposed I could try reprogramming the EPM7128SQC100 and the two AT24C256PC, but I'm not very experienced with using either of them, and I hesitate to risk misprogramming what Ben has probably already correctly programmed.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 13 Nov 2017 15:56:50 GMT View Forum Message <> Reply to Message First thing to check is make sure you have a shorting bar in place to enable U5 as the boot serial flash. See picture below.

Page 6 of 82 ---- Generated from RetroBrew Computers Forum Even without CTS/RTS, the 7-seg display should transition from '8' to '4' (it actually rapidly transition from 8 -> 1 -> 2 ->3 ->4). You can add a loopback wire as shown in the picture and it will then bootup normally with just Xmt and Rcv. In fact you can do all software installation and testing with just Xmt and Rcv but you can't upload/download files with gkermit and extraneous characters may be added when you move the cursor rapidly in microEMACS, but that's much later in the testing phase.

Check the orientation of the 7-segment display, the decimal point should be closest to the edge of the board. Your EPM7128 is programmed and verified. Both 24C256 are programmed and then inserted in my test board to make sure they will boot properly. What is the power supply current draw? At 8MHz clock, it should be around 500mA @ 5V. Look at pin 32 (X2) of the 68681 with scope, you should see 3.68MHz sine wave, roughly 5V peak-to-peak. Look closely at the 68000 pins and how they are inserted in the sockets. The long rows of pins are a bit tricky to lineup and insert properly. Bill

File Attachments 1) Tiny68kPCBrev1bootflash.jpg, downloaded 3403 times 2) DSC_32351113 copy.jpg, downloaded 3395 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Mon, 13 Nov 2017 16:37:12 GMT View Forum Message <> Reply to Message plasmo wrote on Mon, 13 November 2017 10:56First thing to check is make sure you have a shorting bar in place to enable U5 as the boot serial flash.

Oops... I didn't didn't jumper either of them. That's probably what I did wrong. I assembled things in a different order than suggested as I like using an organic flux where I can and hot water cleaning, so I deliberately installed water sensitive components at the very end using no clean solder/flux. And I entirely missed the two-pin headers at T18/19 and T20/21.

If that's not it, I'll continue with your other suggestions.

I did get the LED installed correctly - your photos and construction step 9 description made that easy to get right.

Thanks for the photo of the CTS/RTS jumper. It confirms that I correctly followed the traces for those pins back to the DUART.

Page 7 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 13 Nov 2017 20:55:06 GMT View Forum Message <> Reply to Message My assembly order has more to do with the height of components. I don't want the board to be rocking when I'm soldering so I start with low components and gradually build to the highest ones. You certainly can change the order as you see fit.

You may find the pin length of the jumper too long. I cut about 1/2 of the pin off. The installation of the 2nd serial eeprom is optional. The board in the picture does not even have the 2nd eeprom socket or jumper installed. The 2nd eeprom does give you dual boot capability and an easy way to develop new monitor/debugger or operating system.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Tue, 14 Nov 2017 03:56:34 GMT View Forum Message <> Reply to Message zamp wrote on Mon, 13 November 2017 11:37Oops... I didn't didn't jumper either of them. That's probably what I did wrong.

That was my problem. After I added a jumper across T18/19 and wired up an adapter with CTS and RTS, I was able to go through the entire procedure for installing CP/M-68K on a new compact flash card and it all worked, except that I've not yet been able to send or receive a file using gkermit. I'm using a Mac right now, and I've tried two different Mac terminal emulators (ZTerm and Serial) that supposedly have kermit built in. I have doubts about the kermit implementation in both Mac terminal emulators. One crashes on starting a kermit send and the other hangs or ignores the cancel button in its kermit send dialog box.

I'll try kermit transfers again later this week using a Windows 10 PC.

But there may also be something going on with gkermit on CP/M-68K. The gkermit docs says typing three control-Cs in a row should cancel a gkermit trasnfer, but that only seems to work near the beginning of a gkermit file send. I'm unable to interrupt a gkermit -s or gkermit -r if I've let the transfer attampt run for more than a minute or so.

I used to be pretty up on kermit (I ported it to Primos in the distant past), xmodem, ymodem, and zmodem (in the 80s I integrated those into a couple of Cornell Cooperative Extension BBSs [first on Primos, later on Solaris] that I was the programmer for). While waiting for gkermit tests tonight I dug up an old (1987), simple C version of zmodem. Whether or not I can get gkermit working for me, I'll probably try porting zmodem to CP/M-68K.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 14 Nov 2017 05:34:12 GMT View Forum Message <> Reply to Message Oh boy, this is my fault! I thought I've fixed a bug on my BIOS but I just looked at the BIOS in the

Page 8 of 82 ---- Generated from RetroBrew Computers Forum wiki page and it still have the old bug. The bug is in the conin routine where the incoming data is AND with $7F, so it is 7-bit ASCII characters. Obviously that filters out all control characters. No wonder kermit won't work. I need to figure out what happened to my most current version and update the BIOS in the wiki.

On the other hand, this is great news. I'm glad to hear your hardware is working and able to create a new CF and all seems to be running well (except kermit). Are you running at 8MHz right now? I believe you should be able to run at 12MHz.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Tue, 14 Nov 2017 06:50:56 GMT View Forum Message <> Reply to Message I've got some 12MHz oscillators on order and a couple of 12MHZ 68000, so I should soon have it running faster, but I'm honestly pretty happy with the speed right now.

I think by default Kermit does depend on getting most 8-bit characters through unchanged, but control-C is ascii 3, so ANDing it with 7F should still pass it through unchanged. And typing a control-C at the CP/M seems to be doing what it should. Also, I CAN abort a gkermit transfer as long as I type a few control-Cs shortly after I invoke gkermit.

Digital Research also ANDs with 7F in their example conin. I never did much with 68K assembly code and that was back shortly after the 128K Mac came out, so I don't yet have an eye for reading it. But there's a bit in your conin that looks an awful lot like something that watches for the programmers switch on an old 68K Mac to be pressed and drops into the MacsBug debugger. At some point I'll grab a 68000 reference, your BIOS, and your Tiny68K schematic and try to get a rough feel for what you've written. It'll be a good exercise and should help me actually learn a little of the 68000 instruction set.

Thanks, Ben for working up such a nice hardware design and well documented, repeatable OS install procedure. I'm really enjoying putting this system together. I've never worked with CP/M-68K before and I'm really enjoying picking up a "new" OS. And the huge address space is really nice compared to the few old 8080 and Z80 CP/M systems I used to develop on.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by tingo on Tue, 14 Nov 2017 15:22:02 GMT View Forum Message <> Reply to Message Kermit (in general) doesn't need an 8-bit clean channel. Some versions can be configured to support an 8-bit clean channel.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K

Page 9 of 82 ---- Generated from RetroBrew Computers Forum Posted by plasmo on Tue, 14 Nov 2017 15:38:22 GMT View Forum Message <> Reply to Message I updated the BIOS and the link on wiki page on CF creation so it points to the correct version of BIOS. The updated BIOS is also attached below.

The origin of my BIOS is ERGBIOS.S from the CP/M v1.3 distribution files. The original conin routine did AND $7F with the input and also have a break for MacBug. I removed them when I encountered problems with kermit, but my software revision control is not what it should be.

The current Altera EPM7128 design has one wait state for the memory access. That is not necessary for 8-12MHz CPU clock. I'll soon release an update with zero wait which should speed up the board by about 20%.

A zmodem program for CP/M68K would be very cool. You probably noticed the kermit transfer rate is nowhere near the 38400 speed.

Thank you for the feedback. I have had a great deal of fun working and sharing the design. I hope to collect more feedback, update the board design and have more boards & kits available to interested member in a few weeks. File Attachments 1) TinyBIOS_r5.zip, downloaded 251 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Wed, 15 Nov 2017 00:44:26 GMT View Forum Message <> Reply to Message That was a fast fix, Ben. With tinybios_r5 I'm able to send and receive text files using gkermit and I can at least receive binary (-i) files with gkermit. I've not tried sending binary files yet. gkermit downloaded these executables and they all work: ARC.68K LU.68K SQ.68K USQ.68K

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 15 Nov 2017 01:47:05 GMT View Forum Message <> Reply to Message Excellent! So everything is working? BTW, I'm not familiar with ARC.68K, LU.68K, SQ.68K, and USQ.68K. What are they, and are they available for download? There are not many software for CPM-68K so I'm interested in all software for CPM-68K.

Could you tell me about the brand and size of your CF disk? A user PM me that he is having problem with the creation of CF disk and it sounds like a CF disk problem. There is a particular

Page 10 of 82 ---- Generated from RetroBrew Computers Forum brand of CF (Transcend 128M, 80x) that I intermittently have checksum errors. I know it is not a setup, access, or hold time problem. I'm wondering if I still have issues with CF access.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Wed, 15 Nov 2017 03:03:02 GMT View Forum Message <> Reply to Message Everything does seem to be working. I've not encountered any CRC or other disk errors. The CF card I'm using is a used 128MB Toshiba that I got off of eBay. $23 with shipping for 20 128MB CF cards from China, but they're sold out. The same seller has some other brands of cards for $1.50 and up right now: https://www.ebay.com/sch/mcqo2749/m.html?_nkw=&_armrs=1& amp;_ipg=&_from= . I can send you a few of the 128MB Toshiba cards if you want to try them out.

Those programs are CP/M-68K versions of tools that were used in the old modem download days. Archive creator/extractor, squeeze/unsqueeze (similar to Unix compress/uncompress, but different file format), LU is an all-in-one archiver/unarchiver/squeezer/unsqueezer. I looked for those because I needed to unpack a .LBR for a CP/M-68K version of RUNOFF. LBRs can be unpacked with LU. I found those all at the same site along with some other stuff I've not tried yet. LBRs are kind of nice because you can take a directory full of files and LU them up into a LBR. Then put the LBR someplace safe. CP/M gets cluttered very quickly if you have all of your old projects with many source files all unpacked and spread all over your disks/users. Setting aside a user in a disk for your LBRs lets you keep a text file that lists what all of your LBRs are. For me that's necessary since I have problems remembering what those 8 character filenames mean.

I found all of those archive tools and RUNOFF in the same place: http://www.retroarchive.org/cpm/cdrom/CPM/CPM68K/

What I grabbed from there is this:

68000USQ.LBR 14848 02-09-85 Squeeze/Unsqueeze for CP/M-68K ARC68K.ARC 133888 11-27-87 ARC 5.12 for CP/M-68K COM2X.LBR 23808 09-07-86 No description available CPX2PLUS.DOC 14510 02-22-87 No description available F83V2-68.LBR 237568 02-09-85 No description available KMINCE.LBR 89984 08-29-86 KeyPad editor for CP/M-68K Mince LU.68K 77184 11-20-86 LU for CP/M-68K. See XLU68K.LBR too. MSUTILS.LBR 135424 02-18-88 No description available ROFF4161.LBR 229120 05-22-86 Powerful customizable text formatter SD68K.LBR 27136 06-11-86 No description available SDB.LBR 201856 10-31-86 Simple Data Base for CP/M-68K SNOBOL4.LBR 109696 05-22-86 No description available SYSHACKS.LBR 49792 05-22-86 No description available UTILS.LBR 161408 05-22-86 No description available XLU68K.LBR 171136 11-16-86 Source and Documentation for LU.68K

If you start with LU.68K you can then download .LBR files to your CP/M-68K system and unpack

Page 11 of 82 ---- Generated from RetroBrew Computers Forum them. It's all pretty old-fashioned and not very user friendly. Later this week I'll capture and post a session where I unpack a LBR with LU and describe what I'm doing.

I found some other nice tools and I'm keeping notes on the sources. I'll write it all up and post it somewhere. I could post it here, but I'm not sure if you want to clutter this hardware thread with that stuff. Do you have any suggestions on where to keep track of the stuff we find for CP/M-68K and notes on using it all?

Ben: let me know if you want me to send you a few of these Toshiba CF cards (for free). Sorry I'm not able to do that for everyone. But I'll keep an eye out for more of the Toshiba CF cards and post here if I find some more, especially if I find them at $1 each again.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by computerdoc on Wed, 15 Nov 2017 04:44:09 GMT View Forum Message <> Reply to Message Hi Tiny68K Fans, After much help from Bill troubleshooting my Tiny68K, it all boiled down to a suspicious Transcend 133x 4GB CF Card. It never gave me any good results. I tried a Transcend 80x 512MB card and it works perfectly. No Errors during the pip with verify command when transferring all files from drive E: to drive A:. I'm now looking for a good source for some inexpensive as possible Sandisk cards since that is what Bill has successfully tested with. I've looked on ebay for some good deals. I wish I could buy emass to get the price down. I am interested in getting a few CF cards that work from someone. I'm using TeraTerm to communicate with my Tiny68K. It can transfer files with Kermit among other protocols. How do I transfer several files at once? Or do I have to transfer 1 file at a time? I have tried both ways, but I can't seem to get it to work. Are there any experienced CP/M 68Kers out there to help us all understand how to use CP/M 68K?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 15 Nov 2017 05:14:33 GMT View Forum Message <> Reply to Message RUNOFF!! oh my, have not heard that name for a long long time.

Wow, there are so much information here. I need to chew on them for a long while...

Regarding CF disk: Thank you very much for offering, but I'm actually looking for CF disks that do not work with Tiny68K so I can figure out what's going on. However, $1/disk is a great deal and I'll keep an eye out for that seller. For people wanting a turnkey Tiny68K, it is a good idea to include a CF disk already installed and tested.

I'm looking forward to visit the site and see what software are available. I'll be delighted if you can

Page 12 of 82 ---- Generated from RetroBrew Computers Forum post logs of your exploration here. My hope with Tiny68K is putting out an affordable 68K platform so people can explore the world of 68K and able to share our experiences because we all have a common platform. It is already working for me because I'm new to CP/M and I've learned much already. You've just opened another door and I'm looking forward to learn much much more. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 15 Nov 2017 14:43:24 GMT View Forum Message <> Reply to Message computerdoc wrote on Tue, 14 November 2017 21:44Hi Tiny68K Fans, After much help from Bill troubleshooting my Tiny68K, it all boiled down to a suspicious Transcend 133x 4GB CF Card. It never gave me any good results. I tried a Transcend 80x 512MB card and it works perfectly. No Errors during the pip with verify command when transferring all files from drive E: to drive A:. I'm now looking for a good source for some inexpensive as possible Sandisk cards since that is what Bill has successfully tested with. I've looked on ebay for some good deals. I wish I could buy emass to get the price down. I am interested in getting a few CF cards that work from someone. I'm using TeraTerm to communicate with my Tiny68K. It can transfer files with Kermit among other protocols. How do I transfer several files at once? Or do I have to transfer 1 file at a time? I have tried both ways, but I can't seem to get it to work. Are there any experienced CP/M 68Kers out there to help us all understand how to use CP/M 68K?

Kip, I was so focused on following up to zamp's last message, I completely overlook yours. Congratulation on getting your kit up and running. Troubleshooting over emails never give me the whole picture and I was speculating all over the places. I start to see a trend with the CF issues: the problem may be with the newer, higher speed, large capacity ones. The older, slower, smaller CF are working. I'm confident it is not an setup/access/hold time issue, it is something else. I love to borrow your 133x 4GB CF to chase down the problem. I know gkermit accepts wild card character so you can transfer multiple files. You may have the same kermit problem with previous version of BIOS. I updated the wiki page on CF creation with the new BIOS yesterday morning, so if you were using older files, you should visit the CF creation page again and get the latest. https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k:create_new_cf

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rwiker on Wed, 15 Nov 2017 15:50:26 GMT View Forum Message <> Reply to Message

Page 13 of 82 ---- Generated from RetroBrew Computers Forum My kit arrived here in Norway today - looking forward to assembling and playing with it

Thanks!

Subject: How to install LU.68K, unpack .LBR archives, and PIP (copy) to other user spaces on other drives Posted by zamp on Thu, 16 Nov 2017 02:37:12 GMT View Forum Message <> Reply to Message There are some CP/M-68K .LBR files on the Internet that have tools you may want to unpack. There are many more 8080 or Z80 CP/M .LBR files around that contain source code for programs you may want to try porting to CP/M-68K. A tool that can unpack .LBR files is LU.68K. Here's how you can get a copy of LU.68K on your CP/M-68K computer and use it.

On your host computer (not the target CP/M-68K computer) download these two files: http://www.retroarchive.org/cpm/cdrom/CPM/CPM68K/LU.68K http://www.retroarchive.org/cpm/cdrom/CPM/CPM68K/XLU68K.LBR

Connect to your CP/M-68K computer using a terminal emulator that can send files using the Kermit protocol, then perform the following boldfaced steps.

A>d:

D>user 1

1D>dir (We're going to do this work in an empty spot. User 1 on drive D: is empty on my system.) No file 1D>a:gkermit -r (type this and then start sending LU.68K from your host) G-Kermit CU-1.00, Columbia University, 1999-12-25 Escape back to your local Kermit and give a SEND command.

KERMIT READY TO RECEIVE...

1D>a:gkermit -r (type this and then start sending XLU68K.LBR from your host) G-Kermit CU-1.00, Columbia University, 1999-12-25 Escape back to your local Kermit and give a SEND command.

KERMIT READY TO RECEIVE...

1D>dir D: LU 68K : XLU68K LBR 1D>a:pip a:[g0]=lu.68k (The above PIP copy command may be confusing. Let me break it down into pieces...

Page 14 of 82 ---- Generated from RetroBrew Computers Forum a:pip PIP copies files. The PIP program is over on drive A: I'm in user 1 and on drive D, but I can just refer to A:PIP and CP/M will first look here in 1D:, then in 1A:, and then finally in 0A: where PIP.68K actually lives. a:[g0] This is the destination, 0A:. Because I'm now in user 1, if I said a: instead of a:[g0] PIP would copy it to 1A: instead of to 0A:. = This separates the destination from the source lu.68k The source file to copy from refer to the "CP/M-68K Operating System User's Guide" for lots more of the ugliness of the PIP command.) 1D>era lu.68k (now that lu.68k was copied to a0: we don't need it here in d1:)

1D>dir D: XLU68K LBR 1D>a:lu (start up LU from A0:) XLU68K - Library Utility for CP/M-68K (c) 1986 by Robert Heller -? > -h (ask for help with -h or -?) Command Function ======-o Open library file -c Close library file -x Exit LU -e Extract file(s) -eu Extract and unsqueeze -a Add or replace file(s) -as Squeeze and add or replace file(s) -l List files in library -k Kill file(s) in library -r Reorganize library -h This text -? This text -H > -o xlu68k (open file xlu68k.lbr) lu: old library file XLU68K.LBR has 24 entries, 1 free -O > -l (That's an lowercase L. Either -l or -L will list the files in the directory. The files with a Q in the 2nd character of the extension are sQueezed or compressed.) Name Type Start Length CRC ======DIRECTORY 0 6 0000 LUADD .CQ 6 54 0000 LUCLOSE .CQ 60 8 0000 LUCPM68K.CQ 68 9 0000 LUEXTRCT.CQ 77 33 0000 LUKILL .CQ 110 13 0000 LULIST .CQ 123 13 0000 LUMAIN .CQ 136 34 0000 LUMISC .CQ 170 18 0000 LUOPEN .CQ 188 28 0000 LUREORG .CQ 216 33 0000 LUDEF .HQ 249 14 0000 LUVARS .HQ 263 6 0000

Page 15 of 82 ---- Generated from RetroBrew Computers Forum LU .6QK 269 373 0000 LULINK .SUB 642 1 0000 SQ .CQ 643 127 0000 SQMAIN .CQ 770 17 0000 SQ .6QK 787 203 0000 USQ .CQ 990 50 0000 USQMAIN .CQ 1040 14 0000 USQ .6QK 1054 174 0000 XLU68K .RQF 1228 48 0000 XLU68K .DQC 1276 61 0000 ======Used sectors 1337 Deleted sectors 0 Total sectors 1337 Active entries = 23, deleted = 0, free = 1, total = 24 -L > -eu *.* (Extract and Unsqueeze *.* [all files] in the .LBR archive) sqX0222A -> LUADD.C: unsqueezing, done. LUADD.CQ extracted sqX0222B -> LUCLOSE.C: unsqueezing, done. LUCLOSE.CQ extracted sqX0222C -> LUCPM68K.C: unsqueezing, done. LUCPM68K.CQ extracted sqX0222D -> LUEXTRCT.C: unsqueezing, done. LUEXTRCT.CQ extracted sqX0222E -> LUKILL.C: unsqueezing, done. LUKILL.CQ extracted sqX0222F -> LULIST.C: unsqueezing, done. LULIST.CQ extracted sqX0222G -> LUMAIN.C: unsqueezing, done. LUMAIN.CQ extracted sqX0222H -> LUMISC.C: unsqueezing, done. LUMISC.CQ extracted sqX0222I -> LUOPEN.C: unsqueezing, done. LUOPEN.CQ extracted sqX0222J -> LUREORG.C: unsqueezing, done. LUREORG.CQ extracted sqX0222K -> LUDEF.H: unsqueezing, done. LUDEF.HQ extracted sqX0222L -> LUVARS.H: unsqueezing, done. LUVARS.HQ extracted sqX0222M -> LU.68K: unsqueezing, done. LU.6QK extracted sqX0222N is not a squeezed file LULINK.SUB extracted sqX0222O -> SQ.C: unsqueezing, done. SQ.CQ extracted sqX0222P -> SQMAIN.C: unsqueezing, done. SQMAIN.CQ extracted

Page 16 of 82 ---- Generated from RetroBrew Computers Forum sqX0222Q -> SQ.68K: unsqueezing, done. SQ.6QK extracted sqX0222R -> USQ.C: unsqueezing, done. USQ.CQ extracted sqX0222S -> USQMAIN.C: unsqueezing, done. USQMAIN.CQ extracted sqX0222T -> USQ.68K: unsqueezing, done. USQ.6QK extracted sqX0222U -> XLU68K.RFF: unsqueezing, done. XLU68K.RQF extracted sqX0222V -> XLU68K.DOC: unsqueezing, done. XLU68K.DQC extracted -EU > -x (eXit from the LU utility) lu: old library XLU68K.LBR closed

1D>dir (c=Check out what we unpacked. XLU68K.DOC is the confusing manual for LU. There are also SQ [squeeze] and USQ [unsqueeze] tools here that you could copy to a0: with PIP if you want to.) D: LULINK SUB : LUADD C : LUCLOSE C : XLU68K LBR : LUCPM68K C D: LUEXTRCT C : LUKILL C : LULIST C : LUMAIN C : LUMISC C D: LUOPEN C : LUREORG C : LUDEF H : LUVARS H : LU 68K D: SQ C : SQMAIN C : SQ 68K : USQ C : USQMAIN C D: USQ 68K : XLU68K RFF : XLU68K DOC 1D>ERA xlu68k.lbr (now that it's unpacked you can delete the .LBR - or keep it if that's your preference)

1D>a:

1A>user 0

A> (and we're back in A0: where we started)

Subject: Re: How to install LU.68K, unpack .LBR archives, and PIP (copy) to other user spaces on other drives Posted by plasmo on Thu, 16 Nov 2017 15:34:46 GMT View Forum Message <> Reply to Message Great instruction, worked exactly on my machine as you've described. I have not used USER command much because I don't know the purpose of the command, this is a good method to keep work space apart. In the past I used drive e: (RAMdrive) for scratch area because it is faster and files disappear after power is removed anyway. I compiled and linked the sq.c and sqmain.c programs. The resulting sq.68k works exactly like the original downloaded sq.68k, but when I compare the executable to the original, it is different. I assume it is because the original sq.68k was compiled on a different version of C.

Page 17 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Fri, 17 Nov 2017 15:55:19 GMT View Forum Message <> Reply to Message plasmo wrote on Tue, 14 November 2017 00:34Are you running at 8MHz right now? I believe you should be able to run at 12MHz. I ordered some 12MHz full-size oscillators that just showed up. I swapped out the 8MHz oscillator for 12MHz and the Tiny68K still seems to be working error free. I've not yet tested extensively at 12MHz. I have weekend plans that should involve a lot of edit, compile, test cycles so it'll get a decent workout.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Sun, 19 Nov 2017 21:26:30 GMT View Forum Message <> Reply to Message zamp wrote on Fri, 17 November 2017 10:55I have weekend plans that should involve a lot of edit, compile, test cycles so it'll get a decent workout. My plans were to port Frotz to CP/M-68K, but that didn't pan out. Frotz lets you play Z-Machine games like Zork and Planetfall. But Frotz is nicely written with function and variable names longer than 8 characters as well as #defines of symbol namess longer than 8 characters. And CP/M-68K's version of C allows for: 8 character or less local variable names and #define symbols 6 character or less global variable names and function names I could spend many hours doing global search and replaces to make short #define symbol names, variable names, and function names. And then I'd probably find that other limitations of the C compiler or library might need to be worked around.

I'm going to bail on porting Frotz.

I also wanted to port f2c so that I could compile Adventure. I don't need to play it again, but I like having it on a retro system and it would be nice for demos. And having FORTRAN would also be nice. But I think an f2c port might be tough given the limited Alcyon C math library functions, so at the moment I'm not going to look into what it would take.

I guess I'll give rzsz a go which would give us xmodem, ymodem, and zmodem send and receive. It's sufficiently old that I might be able to get it ported.

But I'm starting to think that CP/M-68K is a bit limiting given how few tools there ever were, how few of them are still to be found in archives, and the lack of source code for some essentials like CP/M-68K 1.3 itself, the C compiler (and preprocessor), assembler, linker, libraries.

I'm looking around for another OS that looks more like Unix and has full source. The most appealing I've come across so far is Alan Cox's FUZIX: https://github.com/EtchedPixels/FUZIX . Source for everything is there and Alan (etchedpixels on this forum) has brought up a limited, one-process version on a 68K emulator: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=101&goto=1279&#msg_1279

Page 18 of 82 ---- Generated from RetroBrew Computers Forum Alan also appears to have bought one of the Tiny68K boards. I'm really hoping he's going to port Fuzix to it. But the lack of an directly-connected Ethernet interface would probably mean a port isn't that appealing to Alan.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 19 Nov 2017 22:37:36 GMT View Forum Message <> Reply to Message What about CPM-68k v1.2? I understand the C source for it is available and the Alcyon C math library is more stable (the floating point library for v1.3 C does not work).

Etchedpixels has both Tiny68K as well as a repurposed SPX MPU board that has CP/M68K installed. I'm hopeful a 68000 FUZIX will become available... soon? Is Ethernet particular important to an useful FUZIX OS? I have a few CS8900 Ethernet controllers I want to try that should fit within the Tiny68K form factor. Alternatively, the 68302 on the repurposed SPX MPU board has a crude SPI interface that maybe sufficiently fast to work with an SPI-to-Ethernet daughterboard.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Sun, 19 Nov 2017 23:09:48 GMT View Forum Message <> Reply to Message plasmo wrote on Sun, 19 November 2017 17:37What about CPM-68k v1.2? I understand the C source for it is available and the Alcyon C math library is more stable (the floating point library for v1.3 C does not work). With CP/M-68K 1.2 we could hack on the OS source if we wanted to change things. I'd like to be able to do that. But the short variable, function, and define names are still pretty limiting for the code I would want to port. I supposed we could work up different C, assembler, and linker that could deal with longer names, but that's more effort than I want to go to. And I'd forgotten how much I disliked CP/M's PIP (which is easily fixed by writing a new copy/cp comand) and limited file system users (0-15 on each drive); I much prefer a filesystem with subdirectories. And I also want environment variables.

I didn't realize the math library in CP/M-68K 1.3 wasn't working. That's not good to hear. plasmo wrote on Sun, 19 November 2017 17:37Etchedpixels has both Tiny68K as well as a repurposed SPX MPU board that has CP/M68K installed. I'm hopeful a 68000 FUZIX will become available... soon? Is Ethernet particular important to an useful FUZIX OS? I have a few CS8900 Ethernet controllers I want to try that should fit within the Tiny68K form factor. Alternatively, the 68302 on the repurposed SPX MPU board has a crude SPI interface that maybe sufficiently fast

Page 19 of 82 ---- Generated from RetroBrew Computers Forum to work with an SPI-to-Ethernet daughterboard. I don't know Alan's thinking on any of this, but if it were me and I was developing an OS that was going to include TCP/IP, then I would want to be targeting hardware that could support Ethernet and/or WiFi. But if Alan were to port Fuzix to the Tiny8K then I'd definitely play around with it even if it couldn't do TCP/IP. Fuzix looks like something I want to learn about whether it's on the Tiny68K or another platform. It really looks like a well thought out OS and I can actually understand the bits of the code that I've looked at. I'm sure much of the code would be over my head, but I do like what I see there.

Another OS that looks interesting is CDOS-68K (find it here: http://www.cpm.z80.de/binary.html) which looks complete, but I can find no documentation at all for it online, other than what is in the help files that are in the CDOS-68K source. Without any documentation on porting it to a new system, it's beyond my ability to tackle.

FreeMINT also looks nice, but it appears that no one is developing it any further. But Fuzix looks like it's being very actively developed.

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. :-)

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Sun, 19 Nov 2017 23:16:29 GMT View Forum Message <> Reply to Message Zamp --

Have you looked into the GCC toolchain that can be used to produce 68k code? The versions of GCC that are part of these toolchains are older than the currently available versions of GCC, but they would probably be a pleasure to work with as opposed to the Digital Research version of C, or Alcyon's.

The downside is that the 68k executable output from the 68k GCC toolchain lacks the header and relocation bits that 68k CP/M seems to like (so you can't run them directly from the command line, as you can a .68k application), but they can be loaded and executed within DDT (using the "R" and "G" functions). It would probably be possible to create a loader application that would load and execute them via BDOS functions. The FORTH interpreter, F83, seems to work that way. I.E. there's a small F83.68k that merely loads and runs F83.BIN.

I built a version of Plasmo's ASCII art program this way (after translating it from BASIC to C), and it is very fast on my homebrew 68k at 12 MHz.

Roger

Page 20 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Mon, 20 Nov 2017 03:04:51 GMT View Forum Message <> Reply to Message zamp wrote on Sun, 19 November 2017 16:26And CP/M-68K's version of C allows for: 8 character or less local variable names and #define symbols 6 character or less global variable names and function names

I just learned there is source for a CP/M-68K version of Alcyon C online. I found links to it at multiple sites, including http:// cpm-connections.blogspot.com/2010/11/list-of-c-compilers-for -cpm.html .

Quote:Alcyon C For CP/M-68K. Includes compiler, assembler, linker and libraries: http://www.cpm.z80.de/download/cpm68k1.zip Floating point library for the 68881 or 68882: [url=http://www.cpm.z80.de/download/lib68881.zip] There are multiple versions of the compiler in this archive, but they are not all complete. I haven't read enough of the code to tell if it can be compiled with the existing CP/M-68K C compiler or if it needs to be compiled on VMS. But I do see that the source for everything is there: C preprocessor, compiler, assembler, linking loader, library tools, C library, math library, include files.

And there is a #define for the symbol size (#define SSIZE 8) that looks to be used through the C preprocessor and compiler, so it might be possible to rebuild all of this to allow longer #define names.

Rons-MacBook-Pro:cpm68k1 amp1$ ls v101 v102 v102a v103 Rons-MacBook-Pro:cpm68k1 amp1$ cd v103 Rons-MacBook-Pro:v103 amp1$ find . -type f -exec grep -l SSIZE {} \; ./cgen/cgen.h ./cgen/main.c ./cpp/lex.c ./cpp/preproc.h ./icode.h ./parser/expr.c ./parser/lex.c ./parser/parser.h ./parser/symt.c Rons-MacBook-Pro:v103 amp1$ I'm not sure if any of the versions of Alcyon C here exactly match what is bundled into CP/M-68K 1.2 or 1.3. I don't know if I'm going to play around with rebuilding the compiler tool chain or not, but it's nice to know the source for some versions IS available.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by computerdoc on Mon, 20 Nov 2017 05:46:33 GMT View Forum Message <> Reply to Message

Page 21 of 82 ---- Generated from RetroBrew Computers Forum Hi Guys, I'm still having great difficulty getting gkermit -r to work. I have Tera Term 4.96 installed and communicating with my Tiny68K just fine. I can send clrcpmmem.s68, cpm15000.s68, tinybios.s68 (v5 but says v0.6), and writeboot.s68 to create the boot code on track 1 of the CF Card. CP/M 68K v1.3 boots just fine. The serial is setup in TeraTerm to com31,38400,8,n,1,hardware. I run gkermit -r and try to transfer via Kermit/send to send the file lu.68k to drive d:, but nothing ever gets sent. The only thing that doesn't work is the kermit transfer. I managed to kermit to work once, but I didn't know I had to transfer/kermit/finish to save the file so I didn't get anything. I have successful before or since. I even tried upgrading the oscillator can from 8MHZ to 12MHZ and this same output was repested. Everything worked EXCEPT for the Kermit transfer. Please Help! Here is the output. ------begin------Tiny68kbug 11/5/17 v0.6, type "he" for help > ..X Valid S record received, executing from starting address S record execution completed > ...... X > ...... X > ...... X Valid S record received, executing from starting address S record execution completed > Tiny68kbug 11/5/17 v0.6, type "he" for help > bo Copying CP/M 68K from Compact Flash...checksum is 0C0DCC9E

CP/M-68K V1.3 COPYRIGHT (C) 1982, 1984, 1985 Digital Research

A>d:

D>a:gkermit -r G-Kermit CU-1.00, Columbia University, 1999-12-25 Escape back to your local Kermit and give a SEND command.

KERMIT READY TO RECEIVE... # N3 Tiny68kbug 11/5/17 v0.6, type "he" for help

Page 22 of 82 ---- Generated from RetroBrew Computers Forum > ------end------Bill, Can you or anyone shed ANY light on this? I can't seem to whip this thing! ARGH! Because I can create a good bootable Track 1, wouldn't it stand to reason that I should be able to transfer a file via kermit? Oh by the way, I still get the Bs in me readme.txt even though I can create the boot code on Track 1 and boot successfully. I have Skype if needed to troubleshoot. Also Teamviewer. Any help is most appreciated. Thanks in advance.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 20 Nov 2017 06:33:33 GMT View Forum Message <> Reply to Message Kip, Once you have saved BIOS and CPM15000 in track1 all you need to do afterward is type 'bo' to boot into CPM. Another word, you only need to load clrcpmmem, cpm15000, tinybios, and writeboot once for each new CF disk.

You can do all file loads and execution and run most CPM executables without hardware flow control, but the extra 'Bs' in microEMACS when you hold down the down arrow key is the surest indication that your hardware handshake is not working. That is the reason gkermit is not working. Tell me about your serial port connections. You obvious have the Rx and Tx wired correctly. What about the RTS and CTS?

Bill

Note: the picture I posted that shows RTS loopback to CTS with a short wire is only a temporary fix to resolve initial communication problems.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by computerdoc on Mon, 20 Nov 2017 08:55:19 GMT View Forum Message <> Reply to Message Hi Bill, I am using the following TTL Serial to MicroUSB Module. < https://www.ebay.com/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-S erial-Adapter-Module-for-Arduino-Mini-Port/141976901783?hash =item210e7b9897:g:jk8AAOSwrklVMjIp> I have RTS of the module connected to CTS input to 68681 and CTS of module to RTS input to 68681. I do boot off the CF Card. I rewrote Track 1 to make sure I had the version 5 of the TinyBIOS file. Should I try some other terminal software?

Page 23 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 20 Nov 2017 13:56:45 GMT View Forum Message <> Reply to Message

Kip, You've seen this picture of the console serial connector pinout in the wiki page. These are all TTL level signals. I like you to do three tests for me: (note: input or output direction are from the persepctive of Tiny68K)

Signal name Signal direction Active level (from perspective (TTL level) of Tiny68K) ------RTS output to PC (output) TTL low (0V) CTS input to 68681 (input) TTL low (0V) Transmit to PC (output) TTL low (0V) Receive to 68681 (input) TTL low (0V) GND VCC

Test 1: With hardware handshake enabled, for PC to send data to Tiny68K, the RTS output must be active (TTL low). Similarly for Tiny68K to send data to PC, CTS input must be active (TTL low). Hook up a meter or scope to the RTS and CTS pins. Since you are able to communicate with Tiny68K, I expect both are TTL low.

Test 2: Does Tera Term has the ability to monitor and manually toggle the handshake signals? I know RealTerm does, and I can do the following exercise in RealTerm: 2a. Select the 'Pins' tab, you should see green light for 'RTS (7)' and over at the Status column you should see green light for 'CTS (8)'. 2b. Turn off power to Tiny68K, you should see 'CTS (8)' light goes out. 2c. Hook up a meter or scope to CTS pin 2d. Turn on power to Tiny68K, CTS pin should measure TTL low, the 'CTS(8)' light at Status column should turn green, and Tiny68K should sign on with the power-on message 2e. click the "Clear" button of 'RTS(7)', you should see the 'RTS(7)' light goes out and CTS pin should measure TTL high level. Type 'he' on the console, you should not receive any character echo back. 2f. Click the 'Set' button of 'RTS(7)', you should see the 'RTS(7)' light turns green and CTS pin should now measure TTL low level, and you should see the characters you typed echo back. This exercise demonstrates PC can send handshake signal to Tiny68K and it will respond properly

Test3: To demonstrate that Tiny68K can send handshake to PC and get the proper response: 3a. Hook a meter or scope to RTS output pin. 3b. Execute microEMACS in CP/M: me readme.txt

Page 24 of 82 ---- Generated from RetroBrew Computers Forum 3c. RTS output should measure TTL low. Press and hold the down-arrow key, you should see RTS output toggling, this is Tiny68K signaling to PC not to send more characters because Tiny68K is busily updating the screen. PC should not send characters to Tiny68K when RTS output is TTL high. 3d. CTS input pin should stay TTL low in this exercise because PC is generally fast enough to handle serial data stream at 38400.

I suspect step 3c is where you are having problem, that RTS output of Tiny68K is not toggling, or that it is toggling but somehow the signal is not coming back to PC to stop it from sending more characters. Which means either the serial-to-USB adapter is not transmit the signal back or the PC software is not responding to it.

That looks like a nice, low cost USB-to-serial adapter. I'll go buy a couple just to try it out. On the next revision of pc board I can create an alternate header for it so the adapter just plug in directly.

File Attachments 1) Console_pinout.jpg, downloaded 3175 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Mon, 20 Nov 2017 14:24:45 GMT View Forum Message <> Reply to Message If you're using one of the TTL to RS-232 adapters like the one in these photos...

...then Transmit, Receive, RTS, CTS, Gnd, VCC from the Tiny68K should all be directly connected to the same-named terminals on the TTL to RS-232 adapter board.

TTL to RS232(DB9 or Tiny68K DB25) adapter ------Receive Receive Transmit Transmit CTS CTS RTS RTS Gnd Gnd VCC VCC

If you're instead using a cable like one of these...

...then you'll have to connect like this

Tiny68K USB to TTL cable ------Receive Transmit

Page 25 of 82 ---- Generated from RetroBrew Computers Forum Transmit Receive CTS RTS RTS CTS Gnd Gnd VCC DO NOT CONNECT VCC OF THIS CABLE TO VCC ON TINY68K

Note that the more common 4-pin cable of this style will not work with the Tiny68K as it doesn't include CTS and RTS. For this type of 6-pin cable, you may need to pull the individual terminals out of the 6-pin housing and rearrange them to match the order of the connector on the Tiny68K.

If you're wondering how to rearrange the terminals in a "dupont" style header or make up your own custom dupont cables (like the one in my first two pictures, you can learn how with this video: https://www.youtube.com/watch?v=GkbOJSvhCgU File Attachments 1) overview.jpg, downloaded 3280 times 2) closeup.JPG, downloaded 3234 times 3) other.PNG, downloaded 3179 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 20 Nov 2017 15:42:03 GMT View Forum Message <> Reply to Message zamp, Thank you! I know there are only 6 signals, but somehow the RS232 hookup causes more grief than operating the rest of the system. I don't know what other people are using, so it is nice to see the pictures of a couple adapters and instruction on how to hook them up. I would really like a common pinout that an adapter can just plug in, no hassel, no tears, but the pinout seems all different. Maybe two or three headers in parallel and just populate the header that fit the particular adapter one has.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Mon, 20 Nov 2017 21:53:29 GMT View Forum Message <> Reply to Message 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

Page 26 of 82 ---- Generated from RetroBrew Computers Forum 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

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Tue, 21 Nov 2017 02:52:02 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by computerdoc on Tue, 21 Nov 2017 05:06:37 GMT View Forum Message <> Reply to Message 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

Page 27 of 82 ---- Generated from RetroBrew Computers Forum side of the board.

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.

File Attachments 1) s-l500.jpg, downloaded 274 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 21 Nov 2017 05:14:11 GMT View Forum Message <> Reply to Message 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

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by computerdoc on Tue, 21 Nov 2017 13:37:42 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 22 Nov 2017 02:21:45 GMT View Forum Message <> Reply to Message 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

Page 28 of 82 ---- Generated from RetroBrew Computers Forum 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

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Wed, 22 Nov 2017 13:20:46 GMT View Forum Message <> Reply to Message 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( 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( 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( and kept both processes around and busy!

Page 29 of 82 ---- Generated from RetroBrew Computers Forum 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 22 Nov 2017 14:52:12 GMT View Forum Message <> Reply to Message 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?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Wed, 22 Nov 2017 18:27:36 GMT View Forum Message <> Reply to Message 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.

Page 30 of 82 ---- Generated from RetroBrew Computers Forum 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

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Wed, 22 Nov 2017 21:29:10 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 23 Nov 2017 01:54:11 GMT View Forum Message <> Reply to Message 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.

Page 31 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by zamp on Thu, 23 Nov 2017 03:30:26 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikemac on Thu, 23 Nov 2017 18:23:35 GMT View Forum Message <> Reply to Message A successful port is a shell/login prompt.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by lowen on Wed, 27 Dec 2017 21:47:41 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 08 Jan 2018 19:04:16 GMT View Forum Message <> Reply to Message 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

Page 32 of 82 ---- Generated from RetroBrew Computers Forum 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).

File Attachments 1) Tiny68K_rev1_fixes_comp copy.jpg, downloaded 300 times 2) Tiny68K_rev1_fixes_solder copy.jpg, downloaded 296 times 3) tiny68k_rev2_CF_fixes copy.jpg, downloaded 335 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Tue, 09 Jan 2018 00:36:23 GMT View Forum Message <> Reply to Message 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

Page 33 of 82 ---- Generated from RetroBrew Computers Forum 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 09 Jan 2018 02:06:11 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Tue, 09 Jan 2018 03:01:59 GMT

Page 34 of 82 ---- Generated from RetroBrew Computers Forum View Forum Message <> Reply to Message 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?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 09 Jan 2018 05:22:03 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Wed, 10 Jan 2018 00:10:56 GMT View Forum Message <> Reply to Message 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

Page 35 of 82 ---- Generated from RetroBrew Computers Forum of a problem.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 10 Jan 2018 04:20:28 GMT View Forum Message <> Reply to Message 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.

File Attachments 1) CF_data_network.jpg, downloaded 1576 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Fri, 26 Jan 2018 04:36:20 GMT View Forum Message <> Reply to Message Interfacing with the serial port seems to be the most troublesome problem with the users of the Tiny68K.

Page 36 of 82 ---- Generated from RetroBrew Computers Forum 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?

File Attachments 1) Prolific USB to DB9.jpg, downloaded 266 times 2) CP2102 usb to serial converter copy.jpg, downloaded 263 times 3) FT232R USB to serial.jpg, downloaded 272 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by Andrew B on Fri, 26 Jan 2018 17:38:48 GMT View Forum Message <> Reply to Message 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.

Page 37 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by lowen on Fri, 26 Jan 2018 18:38:06 GMT View Forum Message <> Reply to Message 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

Page 38 of 82 ---- Generated from RetroBrew Computers Forum 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 ~]$

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikemac on Sun, 28 Jan 2018 18:44:26 GMT View Forum Message <> Reply to Message 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! https://hackaday.com/2018/01/28/the-tiniest-working-68k-system/

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 28 Jan 2018 20:38:19 GMT View Forum Message <> Reply to Message

Page 39 of 82 ---- Generated from RetroBrew Computers Forum 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by lowen on Mon, 29 Jan 2018 16:46:15 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 29 Jan 2018 18:15:34 GMT View Forum Message <> Reply to Message 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

Page 40 of 82 ---- Generated from RetroBrew Computers Forum 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by lowen on Mon, 29 Jan 2018 18:24:00 GMT View Forum Message <> Reply to Message 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.

File Attachments 1) 20180129_133631_resized.jpg, downloaded 1345 times 2) 20180129_133631.jpg, downloaded 240 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Mon, 29 Jan 2018 18:38:43 GMT View Forum Message <> Reply to Message >> .... 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

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 29 Jan 2018 19:36:36 GMT

Page 41 of 82 ---- Generated from RetroBrew Computers Forum View Forum Message <> Reply to Message lowen wrote on Mon, 29 January 2018 11:24The 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. 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! and re-layout the Tiny68K pc board. It runs faster and I have board space for other things.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by pbirkel on Mon, 29 Jan 2018 19:45:05 GMT View Forum Message <> Reply to Message plasmo wrote on Mon, 29 January 2018 11:36lowen wrote on Mon, 29 January 2018 11:24The 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. 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!

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by lowen on Mon, 29 Jan 2018 20:04:17 GMT View Forum Message <> Reply to Message 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).

Page 42 of 82 ---- Generated from RetroBrew Computers Forum 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?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Thu, 08 Mar 2018 07:25:14 GMT View Forum Message <> Reply to Message 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

Page 43 of 82 ---- Generated from RetroBrew Computers Forum a bit newer (C89) than Sozobon and probably generates better code...

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 08 Mar 2018 13:28:53 GMT View Forum Message <> Reply to Message 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&

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Thu, 08 Mar 2018 15:02:15 GMT View Forum Message <> Reply to Message 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

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Thu, 08 Mar 2018 15:18:18 GMT

Page 44 of 82 ---- Generated from RetroBrew Computers Forum View Forum Message <> Reply to Message @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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 08 Mar 2018 15:28:04 GMT View Forum Message <> Reply to Message 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.

Page 45 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Thu, 08 Mar 2018 15:51:23 GMT View Forum Message <> Reply to Message 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.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Fri, 09 Mar 2018 03:35:23 GMT View Forum Message <> Reply to Message @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

Page 46 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 10 Mar 2018 03:49:56 GMT View Forum Message <> Reply to Message Mike, Lots of great ideas and suggestions. I have to do homework and think about them.

The UEXT is unknown to me, but a great idea. Interestingly Tiny68K almost have all the features already, but scattered across several different devices. The DUART has a spare serial port. I2C protocol is used to load serial EEPROM into DRAM. The 68000 processor can read/write the serial EEPROM by bit banging under software control. On rev 2 board there is a real time clock based on DS1302. It is not populated in the boards I shipped but it is populated on my own development board and is working properly. DS1302 uses a different serial protocol not quite like SPI. These serial protocols are fairly easy to implement if operate under software control (bit banging) but run slowly. A fast SPI would require logic resources in EPM7128 that I don't have. I'm rambling; what I'm thinking is that UEXT is a great idea and there are room on board to bring all these signals together in a 10-pin header, the beginning of an UEXT interface.

The Ethernet module I like fit nicely with the UEXT interface; it is the low-cost module based on ENC28J60 uses SPI interface.

I'll start a new topic about Tiny030 and put down what I'm thinking.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Sun, 11 Mar 2018 00:06:58 GMT View Forum Message <> Reply to Message The 28J60 is what I use with socz80. It's not a bad interface. The only trouble I had with it is that the timing diagram on the SPI requires you don't drop chip select too early or violate some of the other delays or *really* weird stuff happens. I spent several days swearing at it trying to work out what I'd done wrong and why only writes to some registers worked until I added delays in the right places!

It does benefit from reasonably fast SPI and also the IRQ line being connected to a GPIO as well as the CS and reset.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by tingo on Tue, 13 Mar 2018 19:09:23 GMT View Forum Message <> Reply to Message mikesmith wrote on Thu, 08 March 2018 08:25 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).

Page 47 of 82 ---- Generated from RetroBrew Computers Forum 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

I'm playing around with this simulator, since I do not have any 68k-hardware at the moment. It compiles easily under FreeBSD. The instructions reads "Grab the BIOS image and CF CP/M image", but from where? I've looked at the Tiny68k board pages https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k but the bios and CP/M images there are .S68 files not .bin files. So I looked for instructions on how to convert the provided files (.S68) to .bin, but didn't find any. Did I miss it?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Tue, 13 Mar 2018 22:23:08 GMT View Forum Message <> Reply to Message Look around on-line. There are converters available. I have "bin2srec" and "srec2bin". Don't remember now where I got them (they are Linux applications), but they work quite well for converting S-records to binary, and vs. versa. Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by tingo on Wed, 14 Mar 2018 22:44:24 GMT View Forum Message <> Reply to Message Duh! I must have been dead tired. I already have srecord installed on my FreeBSD workstation, so two runs with srec_cat and I have the required files. Thanks fro the reminder.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Thu, 15 Mar 2018 06:16:05 GMT View Forum Message <> Reply to Message Looks like you got it solved - I actually pulled the CF image off the card I have.

A quick note in case you missed it in Bill's notes - you will need to byte-swap the image if you want to use cpmtools with it.

I'm still working on the ELF->CP/M converter. Trivial executables work, but stdio is still børked.

Page 48 of 82 ---- Generated from RetroBrew Computers Forum I'm suspicious of the relocation translation, in particular I need to check whether the addend from the RELA records on the ELF side can be ignored (it looks like the 'brownout' ELF->TOS converter ignores them, for example, though that code is far from clear). There are also linker script issues, etc. etc. but those are all manageable if I can get this working...

= Mike

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by tingo on Thu, 15 Mar 2018 10:38:01 GMT View Forum Message <> Reply to Message not sure yet, I only get a black screen when I try to start the emulator. the CP/M image I created with srec_cat was 64 bytes short, so I just added 64 bytes of zero at the end. Perhaps those should be at the beginning?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 15 Mar 2018 13:12:32 GMT View Forum Message <> Reply to Message mikesmith wrote on Thu, 15 March 2018 00:16Looks like you got it solved - I actually pulled the CF image off the card I have.

A quick note in case you missed it in Bill's notes - you will need to byte-swap the image if you want to use cpmtools with it.

Have not thought of this for a while. Early on I was thinkng of using CF to transfer data from PC to Tiny68K. I used the cpmtools to create a CP/M image, copied it to newly formated CF on my PC and moved the CF to Tiny68K. I can see the CP/M image except the upper byte and lower byte of every words are swapped. So the image created in PC was "unswapped" one time in Tiny68K before use. If you move the CF from Tiny68K back to PC, you'll need to swap the upper/lower bytes before PC can read it (I haven't done this before so I'm guessing here).

I believe the byte swap occurred when PC wrote the data to CF because I can take the same CP/M image, converted to Srecord (using BIN2MOT), serially transferred to Tiny68K's RAM disk, and the image received would be correct without byte swapping. In fact, this is the procedure for creating CP/M distro files from PC to Tiny68K. Nowadays I use gkermit to transfer files between PC and Tiny68K so I don't have to deal with byte swapping.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Thu, 15 Mar 2018 15:04:36 GMT

Page 49 of 82 ---- Generated from RetroBrew Computers Forum View Forum Message <> Reply to Message Try running just the ROM first:

# ./py68k.py --target tiny68k --trace-everything bios.bin

Here's a script I use to copy files to the CF for the emulator. Put it in the same directory as 't68k_cpm_disk.bin', which should be a raw dump of the CF from Tiny68k. It needs cpmtools and the diskdefs edit below.

#!/bin/sh # # Create CP/M disk image from a master, adding files to the User 0 area. # # usage:

[...] # master_disk=`dirname $0`/t68k_cpm_disk.bin temporary_disk=`mktemp` output_disk=$1 shift input_files=$* error() { echo $* exit 1 } if [ -z $output_disk ]; then error 'missing output disk file name' fi if [ -z $input_files ]; then error 'missing input file name(s)' fi dd if=$master_disk of=$temporary_disk conv=swab for ifile in $input_files; do cpmcp -f tiny68k $temporary_disk $ifile 0:`basename $ifile` done dd if=$temporary_disk of=$output_disk conv=swab rm $temporary_disk

For cpmtools to work you will need to edit /usr/local/share/diskdefs and add: diskdef tiny68k seclen 128 tracks 62

Page 50 of 82 ---- Generated from RetroBrew Computers Forum sectrk 1024 blocksize 4096 maxdir 512 skew 0 boottrk 1 os 2.2 end

This will only get you access to the first partition, but that's enough for quick tinkering.

HTH, let me know how you get on with the sim...

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Sun, 18 Mar 2018 05:21:44 GMT View Forum Message <> Reply to Message mikesmith wrote on Wed, 14 March 2018 23:16I'm still working on the ELF->CP/M converter. Trivial executables work, but stdio is still børked. I'm suspicious of the relocation translation,

FWIW, this is working well enough now to build a trivial "hello world" program with a relatively current (6.3.0) gcc and have it run under CP/M-68K. I spent a lot of time trying to work out what I had done wrong with the relocation translation when it turned out that I was smashing the first word of the data section due to a missing '0' in a .long directive in crt0.

I'll clean it up and add it as a sample project (with some pointers to toolchains) to the emulator repo. There is still a bunch of work to do (in particular, mapping posix-ish file I/O to the ... interesting CP/M file API), but much of it can be inspired by DRI's code, since they had to deal with this themselves. I see no reason why this would preclude using current (7.x) GCC as well, I just haven't tried to build one yet.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Mon, 19 Mar 2018 22:58:41 GMT View Forum Message <> Reply to Message Any DDT users out there? Noticed anything odd about DDT on the tiny-68k??

I'm trying to debug a small program using DDT. Use the "E" function to load it for execution:

A>ddt

******************************************************** * DDT-68K 9/20/84 Version 1.3 *

Page 51 of 82 ---- Generated from RetroBrew Computers Forum * Serial #XXXX-0000 All Rights Reserved * * Copyright 1982,1983,1984,1985 Digital Research Inc. * ********************************************************

-estore.68k No Symbols text base = 00020100 data base = 000201AE bss base = 000201C6 text length = 000000AE data length = 00000018 bss length = 0000000A base page address = 00020000 initial stack pointer = 006F6962

Everything seems OK, and the load values look fine (come from the header), but if I do (to execute it -- here without breakpoints, but with them result is the same):

-g20100

I get:

Trace --> Next instr:303C0001 at addr:00020106 current Status:00008000

Illegal Instruction at 00020106

Here is the code:

10 00000000 41F900000000 lea.l savit,a0 ; memory pointer 11 * 12 00000006 303C0001 charin: move.w #1,d0 ; BDOS cons. inpt. 13 0000000A 4E42 trap #2 ; call BDOS

I think it is complaining about the "move.w #1,d0"?? Why??

Oh, and if I run the program from the command line (no DDT), it runs fine.

And one other thing: after the "Illegal instruction" message, if I try to get out of DDT (with ^C), CP/M seems to be botched up. Have to reset the tiny-68k and start up CP/M again with "bo".

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 20 Mar 2018 00:31:52 GMT View Forum Message <> Reply to Message Roger, Could you upload the store.68k program? I want to try it on my hardware to make sure it behaves the same here. This is where simulator would be helpful as well and Mike Simith is making progress in that area. Bill

Page 52 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Tue, 20 Mar 2018 00:41:55 GMT View Forum Message <> Reply to Message norwestrzh wrote on Mon, 19 March 2018 15:58 I think it is complaining about the "move.w #1,d0"?? Why??

What does DDT think is in memory? (list using l20100)

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Tue, 20 Mar 2018 01:59:26 GMT View Forum Message <> Reply to Message >> What does DDT think is in memory? (list using l20100)

Looks OK to me (except for my lousy assembler skills!):

A>ddt

******************************************************** * DDT-68K 9/20/84 Version 1.3 * * Serial #XXXX-0000 All Rights Reserved * * Copyright 1982,1983,1984,1985 Digital Research Inc. * ********************************************************

-estore.68k No Symbols text base = 00020100 data base = 000201AE bss base = 000201C6 text length = 000000AE data length = 00000018 bss length = 0000000A base page address = 00020000 initial stack pointer = 006F6962 -l20100 00020100 lea $201C6,A0 00020106 move.w #$1,D0 0002010A trap #$2 0002010C move.b D0,D1 0002010E cmpi.b #$5,D1 00020112 beq $20118 00020114 move.b D1,(A0)+ 00020116 bra $20106 00020118 movea.l A0,A4 0002011A lea $201C6,A0 00020120 adda.l #$80,A0 00020126 cmpa.l A0,A4 -

Page 53 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Tue, 20 Mar 2018 02:06:12 GMT View Forum Message <> Reply to Message Here's the .68k file. SENDC68 strips the header off, so that might not be too useful.

Dump of the program included.

Roger

File Attachments 1) store.sr, downloaded 192 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Tue, 20 Mar 2018 04:31:34 GMT View Forum Message <> Reply to Message (major edit because the previous content is superseded)

I converted your srecords above to ELF, disassembled / reverse engineered to assembler source, assembled and converted back to a CP/M executable. Regardless of whether it's named .68K or .rel, it seems to work in the simulator:

-ecpmtest.68k No Symbols text base = 00020100 data base = 000201B4 bss base = 000201CC text length = 000000B4 data length = 00000018 bss length = 0000000C base page address = 00020000 initial stack pointer = 006F6962 -g20100 12345^E starts at 000201CC ends at 0002024B

(Source attached, please let me know if I missed something in the transliteration) File Attachments 1) crt0.S, downloaded 182 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Tue, 20 Mar 2018 10:30:02 GMT View Forum Message <> Reply to Message The BIOS does not set the trace exception which DDT uses. setexc:

Page 54 of 82 ---- Generated from RetroBrew Computers Forum andi.l #$ff,d1 * do only for exceptions 0 - 255 cmpi #47,d1 beq noset * this BIOS doesn't set Trap 15 cmpi #9,d1 * or Trace

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 20 Mar 2018 12:04:57 GMT View Forum Message <> Reply to Message Roger's Tiny68K has rev 6 BIOS where the trace exception is fixed. Trap15 exception is used by Tiny68K, does DDT uses trap15? setexc: andi.l #$ff,d1 * do only for exceptions 0 - 255 cmpi #47,d1 beq noset * this BIOS doesn't set Trap 15 * cmpi #9,d1 * or Trace * beq noset lsl #2,d1 * multiply exception nmbr by 4 movea.l d1,a0 move.l (a0),d0 * return old vector value move.l d2,(a0) * insert new vector noset: rts

I need to scrub the wiki to make sure they contain the latest software fixes.

------Edit: Roger, my mistake, I forgot your board does not have a CF adapter. You must have installed it recently and downloaded the rev5 BIOS from the Tiny68K wiki. Rev5 BIOS won't work in DDT as uhclem has pointed out. I've updated the wiki page with rev6 BIOS just now. I'll go over the Tiny68K wiki to make sure information are up to date.

The code provided by you and translated by mikesmith is downloaded into my Tiny68K and edited a bit so 68K assembler won't complain and ran it (whew, probably introduced a million bugs by now). It just echoed back whatever I typed. Is this correct?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 20 Mar 2018 13:29:23 GMT View Forum Message <> Reply to Message

Page 55 of 82 ---- Generated from RetroBrew Computers Forum I updated tinyBIOS to rev 6 in the wiki page "Procedure for install a new CF disk" https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:ti ny68k:create_new_cf

The changes from rev5 to rev6 are:

12/19/17 * fix home routine, should be clr.w track * fix setexec routine so trace exception is installed * created a revision word to store BIOS revision at $1B002 * mask off interrupts in 68681. This is because the trace command in DDT does not mask off interrupts

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Tue, 20 Mar 2018 22:03:54 GMT View Forum Message <> Reply to Message The wiki update seems to have fixed the DDT problem. I was able to re-load the newer BIOS on the existing CF OK.

Has the content of the file system download changed (with the update)? Do I need to reload that as well?

What I have from the original build seems to work OK.

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 21 Mar 2018 02:55:26 GMT View Forum Message <> Reply to Message Glad to hear that updated BIOS fixed the DDT problem. The file system has not changed so you don't need to reload it.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Wed, 21 Mar 2018 18:11:54 GMT View Forum Message <> Reply to Message I have another question:

Does the tiny-68k monitor, or BIOS, put the CPU in user mode? Or, does the tiny-68k run in supervisor mode?

Roger

Page 56 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 21 Mar 2018 19:34:14 GMT View Forum Message <> Reply to Message Roger, The monitor runs supervisor mode. It does not change to user mode when transfer control to applications. The CP/M-68K BIOS does not change the mode, either. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Wed, 21 Mar 2018 23:33:24 GMT View Forum Message <> Reply to Message >> The monitor runs supervisor mode. It does not change to user mode when transfer control to applications. >> The CP/M-68K BIOS does not change the mode, either.

Hmmm .... that's strange! When I stuff a privileged instruction (move #$FFFF,SR) into memory (using DDT), and try to execute it, I get a "privilege exception". It's a little difficult for me to interpret the DDT dump of the status register, but I *think* that the supervisor bit is cleared (0). Does DDT do that? Just curious!

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Thu, 22 Mar 2018 00:14:05 GMT View Forum Message <> Reply to Message norwestrzh wrote on Wed, 21 March 2018 16:33> Does DDT do that? Just curious!

Yes and no. All CP/M-68K user programs are run in user mode. (See file ccpload.s in the source. DDT calls the BDOS function (#62) that requests a shift to supervisor mode so that it can dummy up a stack frame for your program before switching to it via a rte instruction. The rte being a privileged instruction.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 22 Mar 2018 02:25:10 GMT View Forum Message <> Reply to Message

Page 57 of 82 ---- Generated from RetroBrew Computers Forum Thanks uhclem for the answer. I don't know the answer to Roger's question but I know when I replaced the 68000 with a 68010 in Tiny68K, I got privilege violation exception and I need to understand why. You've mentioned ccpload.s source, is that available online?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Thu, 22 Mar 2018 03:23:01 GMT View Forum Message <> Reply to Message Source is in the usual place: http://www.cpm.z80.de/source.html

What were you doing to get an exception with the 68010? Were you using the wrong version of DDT?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 22 Mar 2018 04:56:49 GMT View Forum Message <> Reply to Message I tried the 68010 again tonight. I can boot up CP/M-68K, execute the internal commands (type, dir, ren), pip works, but dump does not (get Exception $08 at user address $00021728. Aborted). The simple 'Hello world" C program also get the exception. I can assemble an assembly program, but link68 gets the exception $08.

When run "ddt10 hello.68k" and execute 'g' command, I get:

D>ddt10 hello.68k

******************************************************** * DDT-68K 9/20/84 Version 1.3 * * Serial #XXXX-0000 All Rights Reserved * * Copyright 1982,1983,1984,1985 Digital Research Inc. * ********************************************************

File is relocatable text base = 00020100 data base = 00022E16 bss base = 000231E2 text length = 00002D16 data length = 000003CC bss length = 00000B5C base page address = 00020000 initial stack pointer = 006F6328 -g HelloPrivilege Violation at 00020FF0 PC=00020FF0 USP=006F6066 SSP=0001A928 ST=0009=>IM=0 NEG CRY VBR=00000000 SFC=0 DFC=0 D 00000000 006F5F9F 00000000 00000000 00000000 00000005 00000000 00000000 A 00022E3F 00000004 00020081 00000000 00000000 006F62B6 006F6296 006F6066 move.w SR,D0 -

Page 58 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Thu, 22 Mar 2018 06:18:04 GMT View Forum Message <> Reply to Message plasmo wrote on Wed, 21 March 2018 21:56I tried the 68010 again tonight. ... Privilege Violation at 00020FF0 PC=00020FF0 USP=006F6066 SSP=0001A928 ST=0009=>IM=0 NEG CRY VBR=00000000 SFC=0 DFC=0 D 00000000 006F5F9F 00000000 00000000 00000000 00000005 00000000 00000000 A 00022E3F 00000004 00020081 00000000 00000000 006F62B6 006F6296 006F6066 move.w SR,D0 -

Move from SR is privileged on the '010, and whilst the CP/M sources seem to imply that it was supported as a compilation target, it looks like it wasn't the default.

Note that the '010 exception frame format is different as well...

(edit) It looks like there's code in the BDOS exception handler specifically to handle these issues. I can't quite untangle what the build process is doing, but it looks like it *should* be assembling both into cpmlib, and there's this line in 15/make.sub:

$2lo68 -r -ucpm -um68010 -f $1 -o cpm.rel 2:cpmlib biosa.o vt52.o bios.o 0$2clib that looks like it would be pulling in the '010 exception handler path, but there's a lot of stuff in this directory that's not very clear.

At any rate, if you can build cpm.sys, it looks like the rest of the work's already been done...

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Fri, 23 Mar 2018 00:12:40 GMT View Forum Message <> Reply to Message The build process puts two versions of the exception handler into CPMLIB. It places the 68010 version (conditional assembly selects which one gets built by as68) early in the library.

The linker will only include objects which satisfy some unresolved symbol. (Order of objects within the archive matters! So the 68010 version (except10.o) provides nothing unless you include the command line argument to lo68 making it look for the m68010 symbol. Then when it looks at the 68000 version later on it skips it because all of the symbols in it are already satisfied. Unless you

Page 59 of 82 ---- Generated from RetroBrew Computers Forum are building the 68000 version of course.

When building the 68000 version the linker skips over except10.o because it doesn't have any symbols it needs. But by the time it reaches except.o, another object has been linked that includes an unresolved symbol satisfied by except.o. So it gets linked.

While the manuals do not discuss the 68010 version, there is a readme.txt file on disk1 of the distribution that does.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Fri, 23 Mar 2018 03:05:01 GMT View Forum Message <> Reply to Message uhclem wrote on Thu, 22 March 2018 17:12While the manuals do not discuss the 68010 version, there is a readme.txt file on disk1 of the distribution that does.

Thanks, very educational. So in addition to needing to generate the system for the '010, there's also a separate DDT binary that's required.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Fri, 23 Mar 2018 03:45:48 GMT View Forum Message <> Reply to Message Very helpful Indeed! Since source files and LCPM.sub & LCPM10.sub are associated with ver 1.2 of CPM-68K. Would you suggest I start 68010 with CP/M-68K ver 1.2 first and then migrate to ver 1.3? My goal is CP/M-68K for the 68030.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Sat, 24 Mar 2018 00:35:17 GMT View Forum Message <> Reply to Message plasmo wrote on Thu, 22 March 2018 20:45 Would you suggest I start 68010 with CP/M-68K ver 1.2 first and then migrate to ver 1.3?

Step 1 is to generate CPM.SYS. There should be little difference between 1.2 and 1.3.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Sat, 24 Mar 2018 16:17:07 GMT View Forum Message <> Reply to Message

Page 60 of 82 ---- Generated from RetroBrew Computers Forum plasmo wrote on Thu, 22 March 2018 20:45My goal is CP/M-68K for the 68030.

I searched through my archives and found a version of the exception handler that claims to work with the 68020. I have also noticed that the V1.2 and V1.3 versions are slightly different.

I have no idea where the 68020 version came from or if it works. But I will work on figuring out the differences between the 1.2 and 1.3 version and add the 68020 changes using the 1.2 source as the base since it has good comments.

One interesting difference between the 1.2 and 1.3 versions that I have already found is that the function used to start a user program enables all interrupts in 1.2 and keeps the current interrupt mask in 1.3.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Sat, 24 Mar 2018 18:12:39 GMT View Forum Message <> Reply to Message Yes - because there were systems where enabling all interrupts was broken. That turned on things like high speed timer interrupts, horizontal blank interrupts and the like that system designers intended to be left off. You'll find some BIOSes contain workarounds as a result where the high speed interrupt default vectors to a routine that puts the interrupt mask back where it should be so you only take one hit.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Sun, 01 Apr 2018 13:00:12 GMT View Forum Message <> Reply to Message plasmo wrote on Tue, 20 March 2018 05:04 Trap15 exception is used by Tiny68K, does DDT uses trap15? That is actually an interesting question.

The BDOS exception code initializes most vectors to point into a table within it. This is just a series of "bsr except" instructions. That code uses the return address left on the stack to calculate which exception happened. It then sets things up to call the user program in user mode if the user has setup a vector. Otherwise the default action is taken which is to print an error message and do a warm boot.

But if you look at that series of bsr instructions you will find that it ends with a couple of NOP instructions. These do not appear in the source file "exceptn.s". A mystery I didn't worry about too much until I looked at the assembler output for the code I am working on.

I found that the assembler was replacing the last bsr instruction in the table with those two NOPs because the "except" label immediately follows. The 68010 version has the privlege violation code

Page 61 of 82 ---- Generated from RetroBrew Computers Forum here so this doesn't happen. I could understand the replacement, perhaps, if this were a branch instruction.

Looking at the assembler source I see a comment from [vlh] showing that this was added in the 4.2 version and one routine seems to handle both branches and branches to subroutines. It could be fixed but this is not something that is going to turn up often.

The entry that is replaced with NOPs happens to be trap #15. So while CP/M-68K isn't using trap #15 for anything, it does initialize the vector.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Sat, 06 Oct 2018 08:30:32 GMT View Forum Message <> Reply to Message In case anyone is interested, I built a new CCP and BDOS for the 68010. Instructions and information are on the RBC Wiki at this page

I also placed a pre-built binary there.

I've never really used CP/M so some of what I wrote might be incorrect, but the build process appears indeed to be as uhclem describes it. The end result of my instructions is a CPM15000 binary that works correctly with the 68010 (has the exception handler and 68000 stack frame emulation).

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 06 Oct 2018 16:20:05 GMT View Forum Message <> Reply to Message This is delightful. I have tried 68010 on Tiny68K and many CPM programs would crash exactly as you've described. I'm going to try your instruction when I get home tonight. A note about DS1302: I have routed active signals within the exclusive zone of DS1302 so you'll notice that the RTC runs fast when the board is powered but keeps correct time with the board powered down. I plan to try shielding or reroute the active signals to correct the timing problem but they are still on my to-do list. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Sat, 06 Oct 2018 18:00:57 GMT View Forum Message <> Reply to Message >> In case anyone is interested, I built a new CCP and BDOS for the 68010.

Page 62 of 82 ---- Generated from RetroBrew Computers Forum You can be sure that someone is interested!!! Thank you!

I've built a new 68010 CCP/BDOS using your instructions. Worked great. The SENDC68 part is a little dodgy, but I have other ways to copy the new CPM .BIN file to the host machine, so no worries. I had no idea that there was a 68010 module in the CLIB!

I'm going to try it out asap. A friend has been trying to run CP/M 68k on a 68020, and having problems with privilege violations. I suspect that this information will help him as well!

Thanks again.

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Sun, 07 Oct 2018 01:37:35 GMT View Forum Message <> Reply to Message Hi everyone - no worries, I'm glad that the information might come in useful .

The SENDC68 part is not as bad as it sounds. S-Record data is 100% ASCII by design, so I think it's quite acceptable to directly copy and paste it, as it is text.

I had to paste all the S-Record data for CP/M into my terminal when first preparing my CP/M-68K CF card as I didn't have a program at hand that could "send" text files .

I tried to use GKERMIT to copy the built binary across, but it does not work for me with TeraTerm (Windows). I am using a genuine FTDI serial cable - I have heard that this can cause issues?

(I will need to transmit an XModem or ZModem terminal program to my Tiny68K if one exists).

I don't think that there's a 68010 module in the CLIB, it's in the CPMLIB. The CLIB is just included as that is what was used in the original SUB files.

Regards,

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 07 Oct 2018 05:23:40 GMT View Forum Message <> Reply to Message Ugh! All my Tiny68K are committed to one project or another so I'll have to build another one to

Page 63 of 82 ---- Generated from RetroBrew Computers Forum try out the 68010.

One comment on your instruction: The command to initialize assembler for the first time is as68 -i as68init which will generate the as68symb.dat file. If you use my CP/M image file 't68kram.s68', the as68symb.dat is already generated so it is not necessary to initialize the assembler.

I can't read the value of your crystal oscillator. Tiny68K is designed for 12MHz operation so you should be able to run it at 12MHz. There is pretty good chance you can overclock it to 16MHz.

GKERMIT requires hardware shakes. There were lengthy discussion about the hardware handshakes on this thread around late January 2018. I was unsuccessful with FTDI serial adapter in Windows (tried several terminal programs, including TeraTerm). Ultimately I used CP2102 adapter and wired it like the second picture of this post: https://www.retrobrewcomputers.org/forum/index.php?t=msg& ;th=222&goto=4148&#msg_4148

Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by jbforrer on Sun, 07 Oct 2018 06:24:46 GMT View Forum Message <> Reply to Message Greetings,

Interesting developments --- thanks for sharing the details on preparing the CCP/BDOS for 68010.

I've encountered the same privilege exception on my "Simple 68020" SBC and found the issue was "move.w SR, D0". With the new 68010 CP/M, programs now seem to run OK. The only exception I have is CB68 which error:

------CB68 CBASIC Compiler Version 1.0 Serial No. 3123-0000-000061 All Rights Reserved Copyright (c) 1983 Digital Research, Inc. ------end of pass 1 invalid file name:

Almost look like a temporary file was created that it could not locate? I have not spent much time debugging that one.

Cheers. Johan.

Page 64 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Sun, 07 Oct 2018 06:36:59 GMT View Forum Message <> Reply to Message Thanks for the feedback, I have fixed up the initialisation line (oops!). Yes your image does not require it, I only included it for completeness.

My oscillator is 8MHz as I didn't initially realise that the Tiny68K was designed for higher speeds. Yesterday I ordered 10MHz, 12MHz and 16MHz oscillators. It will be interesting to test them.

My FTDI does have hardware handshaking enabled and connected (without this, the monitor waits indefinitely) but something is definitely wrong which I assume is FTDI specific. I spent a little bit of time with GKERMIT in debug mode (-d) and the debug output seems to indicate missing or corrupted data. Very odd. Thanks for the information, I may just purchase a CP2102 adapter.

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Sun, 07 Oct 2018 22:45:54 GMT View Forum Message <> Reply to Message Rosario --

My tiny68k is running with a ~14.5 MHz oscillator. No other changes.

>> .... I may just purchase a CP2102 adapter.

Don't know anything about the "FTDI adapter", but I'm using the CP2102. No problems with it. GKERMIT works fine (with SuSE Linux and minicom).

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 08 Oct 2018 15:48:11 GMT View Forum Message <> Reply to Message rvumbaca wrote on Sat, 06 October 2018 02:30In case anyone is interested, I built a new CCP and BDOS for the 68010. Instructions and information are on the RBC Wiki at this page

I also placed a pre-built binary there.

I've never really used CP/M so some of what I wrote might be incorrect, but the build process appears indeed to be as uhclem describes it. The end result of my instructions is a CPM15000 binary that works correctly with the 68010 (has the exception handler and 68000 stack frame emulation).

Page 65 of 82 ---- Generated from RetroBrew Computers Forum rvumbaca,

I built up another Tiny68K and populated it with a 68010. Followed your instruction and it is now working, but with a correction:

The command format for sendc68 is: sendc68 - cpm15000.,bin >cpm010.s68

Furthermore, the sendc68.68k command can't run on the 68010 without the updated CP/M. It will error out with Exception $08. Neither will GKERMIT run on 68010 without the CP/M being updated first. So I have to run your procedure on a Tiny68K with 68000 processor, GKERMIT out the updated CP/M and then install that on the Tiny68K with 68010.

I see you've included the S record of the updated CP/M in your page. That is a much easier way.

The updated CP/M should also work with 68020/030. I need to fire up my Tiny020 or Tiny030 and see whether I can run the modified CP/M on them.

A wonderful upgrade, thank you!

Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Tue, 09 Oct 2018 12:21:18 GMT View Forum Message <> Reply to Message Hi Johan,

"move.w SR, D0" is the privileged instruction that causes the exception on the 68010. I guess we can conclude that it is privileged on the 68020 too (without checking the 68020 manual)..

The CB68 problem is weird, it does look like it can't find a temporary intermediate file. I feel like I saw that problem too, when I first used a 68010 with the 68000 BDOS and CCP. I'll have to try it out again..

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Tue, 09 Oct 2018 12:25:06 GMT View Forum Message <> Reply to Message Hi Roger,

Page 66 of 82 ---- Generated from RetroBrew Computers Forum FTDI are a very popular manufacturer of USB bridges, they also make cables with their chips buil-in. Their products are so popular, they were cloned by Chinese manufacturers (and then FTDI bricked all the counterfeit products)

The CP2102 is easy to obtain, thanks for the confirmation, I am going to order one of those. I wonder what the technical reason for the problem is..?

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Tue, 09 Oct 2018 12:48:22 GMT View Forum Message <> Reply to Message Hi Bill,

I'm glad this was useful and thanks for the feedback! I probably shouldn't have waited one week between doing the re-build and writing the instructions

I have made a few corrections to my instructions, I also added a new section mentioning that the 68020/68030 can also benefit from this.

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Tue, 09 Oct 2018 21:44:57 GMT View Forum Message <> Reply to Message It's privileged on all but the 68000/68008 based cores. Motorola wanted the CPU to be virtualizable and the 68000 couldn't quite virtualize. Sadly it took another 30 years before anyone except IBM got why virtualization was a cool trick.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Tue, 09 Oct 2018 21:56:02 GMT View Forum Message <> Reply to Message The 68020 adds some more stack frame types and lengths. But the thing you are likely to run into first is the instruction cache.

The CP/M-68K exception handler changes the offending move from SR instruction to a move from CCR then tries again. But on the 68020 the offending instruction will still be in the cache. So unless you want to run with the cache disabled, the exception handling code must also clear that cache entry.

Page 67 of 82 ---- Generated from RetroBrew Computers Forum I think I have an attempt at an except20.s around here somewhere...

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Tue, 09 Oct 2018 22:28:18 GMT View Forum Message <> Reply to Message You need the caches off on a 68020+ in order to run CP/M 68K. It doesn't understand cache flushing in all the other places it is needed, and neither do the apps.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Tue, 09 Oct 2018 22:37:34 GMT View Forum Message <> Reply to Message I was wondering if caches would be a problem on 68020+, thanks for confirming!

Johan - Might be worth trying CP/M on your 68020 with caches disabled before you boot CP/M?

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Wed, 10 Oct 2018 06:25:16 GMT View Forum Message <> Reply to Message There's only one cache on the '020 (the instruction cache), so the only time you need to do anything with it is when you have modified memory that (may) contain code.

This is why patching move SR -> move CCR needs the relevant cache line to be invalidated (write the address you just patched into CAAR and set the CE bit (2) in CACR).

Aside from that, you can probably make quite a bit of progress by setting the C bit in CACR in various strategic places (before jumping to a loaded program, for example), but any programs that think they know how to load / modify their own code are going to fail unpredictably and there's very little you can do about it...

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Wed, 10 Oct 2018 06:56:40 GMT View Forum Message <> Reply to Message As a slight change of subject - this thread resurfacing prompted me to publish my stalled but possibly still interesting port of libgloss / newlib to cpm68k. https://github.com/John-Titor/newlib-m68k

Page 68 of 82 ---- Generated from RetroBrew Computers Forum This essentially lets you use gcc as a cross compiler targeting cpm68k. You'll need Crosstool-NG to generate the compiler (configuration is included), and some way of getting the resulting binary onto your target system. It borrows from the original DRI CP/M sources, as well as inspiration from various Atari projects (Brownout in particular).

Most things are implemented and should work, but it needs more testing...

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by jcoffman on Wed, 10 Oct 2018 15:01:46 GMT View Forum Message <> Reply to Message The CP/M-68 implementation on the ECB Mini-M68k (68008) and ECB KISS-68030 boards compiles from the same code -- with some conditionals. I do not remember having any trouble bringing up the 68030 version with issues related to caching. But CP/M-68 on the 68030 has not received much usage since Will's Linux port is the more useful OS for the KISS-68030 board.

--John

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by jbforrer on Wed, 10 Oct 2018 18:54:05 GMT View Forum Message <> Reply to Message Greetings rvumbaca,

Thanks again for posting your 68010 CP/M-68K procedure. Solved many issues I encountered. I started again with fresh image and now all is working. Think my files got damaged with all the attempts.

Incidentally, I have 68020 cache off, so that is not an issue with this experiment. Also, a pity CP/M-68K does not utilze VBR to remap ROM vectors. I had to kludge up a phantom ROM/RAM scheme to try CP/M-68. It does work and actually a nice little system.

Johan.

A>cb68 asciiart ------CB68 CBASIC Compiler Version 1.0 Serial No. 3123-0000-000061 All Rights Reserved Copyright (c) 1983 Digital Research, Inc. ------end of pass 1 end of pass 2

Page 69 of 82 ---- Generated from RetroBrew Computers Forum 1: 10 for y=-12 to 12 2: 20 for x=-39 to 39 3: 30 ca=x*0.0458 4: 40 cb= y*0.08333 5: 50 a=ca 6: 60 b=cb 7: 70 for i=0 to 15 8: 80 t=a*a-b*b+ca 9: 90 b=2*a*b+cb 10: 100 a=t 11: 110 if (a*a+b*b)>4 then goto 200 12: 120 next i 13: 130 print " "; 14: 140 goto 210 15: 200 if i>9 then i=i+7 16: 205 print chr$(48+i); 17: 210 next x 18: 220 print 19: 230 next y end of compilation no errors detected code area size: 738 000002e2h data area size: 88 00000058h common area size: 0 00000000h symbol table space remaining: 49687

A>link68 asciiart,cb68.l68 ------LINK68 Overlay Linker Release 0.f Serial No. XXXX-0000 All Rights Reserved Copyright (c) 1983 Digital Research, Inc. ------asciiart,cb68.l68

A>asciiart 000000011111111111111111122222233347E7AB3222221111000000000000000000000000000 00 000001111111111111111122222222333557BF754332222111110000000000000000000000000 00 000111111111111111112222222233445C 643332222111110000000000000000000000000 011111111111111111222222233444556C 654433332211111100000000000000000000000 11111111111111112222233346 D978 BCF DF9 6556F4221111110000000000000000000000 111111111111122223333334469 D 6322111111000000000000000000000 1111111111222333333334457DB 85332111111100000000000000000000 11111122234B744444455556A 96532211111110000000000000000000 122222233347BAA7AB776679 A32211111110000000000000000000 2222233334567 9A A532221111111000000000000000000

Page 70 of 82 ---- Generated from RetroBrew Computers Forum 222333346679 9432221111111000000000000000000 234445568 F B5432221111111000000000000000000 864332221111111000000000000000000 234445568 F B5432221111111000000000000000000 222333346679 9432221111111000000000000000000 2222233334567 9A A532221111111000000000000000000 122222233347BAA7AB776679 A32211111110000000000000000000 11111122234B744444455556A 96532211111110000000000000000000 1111111111222333333334457DB 85332111111100000000000000000000 111111111111122223333334469 D 6322111111000000000000000000000 11111111111111112222233346 D978 BCF DF9 6556F4221111110000000000000000000000 011111111111111111222222233444556C 654433332211111100000000000000000000000 000111111111111111112222222233445C 643332222111110000000000000000000000000 000001111111111111111122222222333557BF754332222111110000000000000000000000000 00 000000011111111111111111122222233347E7AB3222221111000000000000000000000000000 00

A> ======not sure the text on the posting displayed correctly ... it is supposed to look like the usual pattern =====

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by UhClem on Wed, 10 Oct 2018 19:10:33 GMT View Forum Message <> Reply to Message jbforrer wrote on Wed, 10 October 2018 11:54Also, a pity CP/M-68K does not utilze VBR to remap ROM vectors. I had to kludge up a phantom ROM/RAM scheme to try CP/M-68.

The BDOS does all of its access to the vectors via BIOS calls. So the decision on using the VBR is made by whoever writes the BIOS.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by jbforrer on Thu, 11 Oct 2018 02:27:55 GMT View Forum Message <> Reply to Message @uhclem

OK, that's useful to know.

For TinyBIOS, CP/M probably sets vector addresses in the "setexec" routine (Trap #3 function 22). Looks like something that can be made to work for 68010+ VBR. I'll have to experiment with the idea.

Page 71 of 82 ---- Generated from RetroBrew Computers Forum setexc: andi.l #$ff,d1 * do only for exceptions 0 - 255 cmpi #47,d1 beq noset * this BIOS doesn't set Trap 15 * cmpi #9,d1 * or Trace * beq noset lsl #2,d1 * multiply exception nmbr by 4 movea.l d1,a0 move.l (a0),d0 * return old vector value move.l d2,(a0) * insert new vector noset: rts

Thanks.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Thu, 11 Oct 2018 11:50:21 GMT View Forum Message <> Reply to Message mikesmith wrote on Tue, 09 October 2018 23:25There's only one cache on the '020 (the instruction cache), so the only time you need to do anything with it is when you have modified memory that (may) contain code.

This is why patching move SR -> move CCR needs the relevant cache line to be invalidated (write the address you just patched into CAAR and set the CE bit (2) in CACR).

Aside from that, you can probably make quite a bit of progress by setting the C bit in CACR in various strategic places (before jumping to a loaded program, for example), but any programs that think they know how to load / modify their own code are going to fail unpredictably and there's very little you can do about it...

For a fair amount of stuff you can get somewhere by flushing the cache in the BIOS after any disk read rather than trying to patch CP/M 68K in strategic places.

Alan

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Sat, 26 Jan 2019 20:28:03 GMT View Forum Message <> Reply to Message Tiny68K now has Fuzix running on it as the first real 68K platform.

It's not entirely done yet. There are a long list of userspace funnies to iron out and some things

Page 72 of 82 ---- Generated from RetroBrew Computers Forum that need addressing in terms of scaling and performance but it does work. In theory it should be possible to make it self hosting but that means cross building a ton of stuff to get ansi pcc up and running on it.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikemac on Mon, 28 Jan 2019 15:18:19 GMT View Forum Message <> Reply to Message Congratulations!

Although self hosting is a good test of the system and definitely a bragging point, I doubt it'd be very practical. What does "practical" have to do with retro computing? On one of the KISS68K YouTub videos I was watching the other night, they mentioned it'd take 45 hours or so to compile the Linux kernel. Good to do once to show it can be done. But since cross compiling the kernel took a couple of minutes, self hosting wasn't entirely useful.

Now, being able to compile and debug! user apps on the system is a lot more useful.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by jcoffman on Mon, 28 Jan 2019 19:04:27 GMT View Forum Message <> Reply to Message I have not seen the YouTube video(s), but Will S. contributed the cross-compiled Linux for the KISS-68030.

CP/M-68 has always been a part of the BIOS for that ECB CPU board. It is also possible to boot CP/M-68 from media. It is the same CP/M-68 that runs on the Mini-68K (68008), except for the CPU-specific fault handling.

--John

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Mon, 28 Jan 2019 19:13:38 GMT View Forum Message <> Reply to Message Some of that depends upon the choice of compiler. Back in the day we used to build fairly complex games on Amiga and ST machines and with Lattice C it was quite usable even with much slower storage than today. The older compilers like Sozobon and PCC don't produce quite such good code given arbitrary input but given reasonably sensible code input actually produce output that's often not far off gcc.

Page 73 of 82 ---- Generated from RetroBrew Computers Forum In addition of course there are hot spots you can hand tune to get the compiler to do the right thing.

By way of comparison the Fuzix kernel is smaller than V7 Unix, and it was routine to rebuild that on a PDP/11 slower than the 68000 and with the pre-ANSI version of PCC. A minimal current Linux 68000 kernel binary is 2.5MB code without networking (I know because I've mostly built one for Tiny68K but after seeing the size never got around to writing the tty driver). The Fuzix kernel binary is about 40K code

Alan

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 07 Sep 2019 17:23:01 GMT View Forum Message <> Reply to Message I recently discovered a "feature" of Tiny68K (as well as T68KRC) that was not in the original design nor was it documented. Since there are a number of Tiny68K users in this forum, I thought it may be of interests.

Tiny68K has an on-board I2C bus used to load the serial EPROM (AT24C256) to memory immediately after reset. By design there are two serial EPROM on board allowing Tiny68K to boot to two different operating environments based on a jumper selection. It turns out the 2nd serial EPROM (U7) is seldom used and by sheer coincidence the pin assignments of U7-5 to U7-8 match the I2C bus pin assignments of the common 128x64 OLED I2C display except U7-7 which is write protect and left floating by design. By jumper U7-7 to ground and remove the socketed AT24C256, a 128x64 OLED display can plug directly into the socket as shown in the attached picture.

Attached is also a simple program that initialize the 128x64 display and fill its graphic memory with ASCII table.

Bill

File Attachments 1) Tiny68k-oled-closeup.jpg, downloaded 839 times 2) DSC_47130906.jpg, downloaded 116 times 3) tstSSD1306.zip, downloaded 96 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by frax on Sun, 15 Sep 2019 14:53:01 GMT

Page 74 of 82 ---- Generated from RetroBrew Computers Forum View Forum Message <> Reply to Message Just finished building my rev 2.1 but the 7-seg is stuck on 8 and I don't have any action on the serial port. I have visually inspected everything a few times but can't see anything obviusly wrong.

Do you know if you programmed the 24C256? I got two, switching the jumper made no change. I also noticed a few missing resistors, R16 near the voltage supervisor feels kinda vital or? And also R1 and R15 but those doesn't seem to be installed on your pictures.

FYI, I put the jumper on the USB dongle so I can use it for power, see the red wire on the pictures.

File Attachments 1) back.jpg, downloaded 104 times 2) top1.jpg, downloaded 103 times 3) top2.jpg, downloaded 106 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 15 Sep 2019 17:34:54 GMT View Forum Message <> Reply to Message Hi frax, The current consumption of Tiny68K is quite high, around 600mA, so the CP2102 is unlikely to supply the needed current. That's the most likely problem.

R16 is not needed because the voltage supervisor has an internal 4.7K pull up resistor already. R1 & R15 are not needed. Both 24C256 should be programmed already along with the CPLD & CF disk, so you should not need to program anything.

The 7-seg display is the most reliable way of showing the bootup progress of Tiny68K. The display is very similar to T68KRC's 7-segment display. When it is initially powered up, it stays at "8" for a moment, then very rapidly roll through "0" thru "4", and then "7" and finished with the blinking segments in succession. Let me know how it is going.

Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by frax on Mon, 16 Sep 2019 18:17:00 GMT View Forum Message <> Reply to Message Tried powering it using a seperate 1A adapter, same thing. I'll take it to my workbench and do some measuring.

Page 75 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Tue, 17 Sep 2019 02:29:34 GMT View Forum Message <> Reply to Message Hi frax, After power-on reset is negated (250-350mS) from power on, you should see lots of activities on pin 5 and pin 6 of the U5 and U7 (AT24C256). This is the CPLD state machine loading 32K bytes of program into DRAM via I2C bus. During this time the 68000 reset (68000 pin18) should be asserted (low). Once I2C loading is completed, reset is negated and 68000 should start running. Address strobe (68000 pin 6) should be toggling continuously. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by b1ackmai1er on Mon, 23 Sep 2019 07:56:28 GMT View Forum Message <> Reply to Message Hi Gents,

I have think I have my EPM7128 soldered on without any bridges. Do I just need P2, R2, R13 and VCC to program this to confirm it is working?

Thanks.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 23 Sep 2019 23:47:18 GMT View Forum Message <> Reply to Message Hi Phil, I'm away from home and can only check in once in a while. Yes, all you need to program the CPLD is the programming header, the two associated resistors and you should be able to program it. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 22 Feb 2020 21:27:08 GMT View Forum Message <> Reply to Message I received a couple MC68012 in PGA package in the mail. I understand there are half dozen people with MC68012 in the retrobrewcomputers community, so I revised the Tiny68K design, removing the giant 64-pin 68000 DIP and replacing it with the compact 68012 PGA. In the space freed up, I put two 8-bit I/O expansion slots. I also take this opportunity to fix the compact flash interface and have a better (quieter) RTC circuitry. The PC board design is at JLCPCB now. There is also a homepage for MB012 here:

Page 76 of 82 ---- Generated from RetroBrew Computers Forum https://www.retrobrewcomputers.org/doku.php?id=builderpages: plasmo:mb012

File Attachments 1) mb012_r0_jlcpcb_2-22-20.png, downloaded 505 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Wed, 04 Mar 2020 14:12:50 GMT View Forum Message <> Reply to Message Received my most recent batch of pc boards from China yesterday. It took 10 days to produce these boards instead of the normal 5-day turnaround. Among them is the pc board for MC68012. This is MB012 fully populated. It is very similar to Tiny68K so only requires minor modifications of the Tiny68K software and CPLD equations. Bill File Attachments 1) MB012_annotated.jpg, downloaded 114 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by etchedpixels on Wed, 04 Mar 2020 14:33:17 GMT View Forum Message <> Reply to Message Nice. You didn't fancy wiring it to a 2GB memory then 8)

With my emulator hat on can I ask what the minor differences are ? I can already emulate Tiny68K/T68KRC with 68010 CPU.

Alan

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Thu, 05 Mar 2020 01:43:54 GMT View Forum Message <> Reply to Message 16 meg for 68010 is already ridiculously large, so I don't see the memory getting any bigger. The biggest change is the CF interface is now 8-bit wide instead of the 16-bit interface. Since it is an 8-bit interface, the byte order will be correct. The other change is DS1302 RTC should work without the clock running fast. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K

Page 77 of 82 ---- Generated from RetroBrew Computers Forum Posted by plasmo on Wed, 18 Mar 2020 15:10:55 GMT View Forum Message <> Reply to Message It turns out I have a number of 68000 in PGA package so I tried one of them out on MB012. Ha, it works! Bill File Attachments 1) DSC_56370318.jpg, downloaded 152 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Sat, 21 Mar 2020 01:58:44 GMT View Forum Message <> Reply to Message Hi Bill, plasmo wrote on Wed, 18 March 2020 08:10It turns out I have a number of 68000 in PGA package so I tried one of them out on MB012. Ha, it works! Bill Nice work! However I am a little confused. I thought that the PGA 68000 was 68 pins and the PGA 68012 was 84 pins. But they look to be the same size in your photos??

Regards

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 21 Mar 2020 04:51:00 GMT View Forum Message <> Reply to Message Rosario, Both 68000 and 68012 PGA are 10x10 PGAs. 10x10 PGA can have as many as 100 pins, 68000 has two outer rings plus 4 corner pins of the third ring while 68012 has three rings. The added address lines of 68012 are in the inner ring. Since I only use 16 meg of address lines in MB012 design, the high order addresses of 68012 are not connected at all. Bill

File Attachments 1) 68000_68010PGA.jpg, downloaded 355 times 2) 68012PGA.jpg, downloaded 317 times

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K

Page 78 of 82 ---- Generated from RetroBrew Computers Forum Posted by rvumbaca on Sat, 21 Mar 2020 06:04:00 GMT View Forum Message <> Reply to Message Hi Bill,

Thanks for the explanation, makes sense! I guess Motorola intended it this way, to allow for different options on the same board (as you have done).

Regards,

Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by norwestrzh on Sat, 21 Mar 2020 17:22:35 GMT View Forum Message <> Reply to Message Hi Bill,

Other than the more compact footprint (and increased memory space -- if you use the added address pins), are there any advantages to the 68012 over, say, the 68010? I assume that the 68012 has the added capabilities of "page swap" that the 68010 has, so I think I can see the advantages over the 68000?

Just curious.

Roger

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sat, 21 Mar 2020 18:12:24 GMT View Forum Message <> Reply to Message Roger, 68012 can directly access 2 gig of memory which is ridiculous amount given the performance of the CPU is no faster than 68010. Other than that, there are no differences between 68012 and 68010. I kept the memory the same as Tiny68K, I.e., 16 meg, so it is compatible with 68000/68010/68012. I like to hear applications that can use memory more than 16meg.

I design the new board mainly because the availability of 68012 and I also have found a cache of 68000 PGA. A more economical design IMO would be based on 68000/68012 in PLCC packages. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K

Page 79 of 82 ---- Generated from RetroBrew Computers Forum Posted by mikesmith on Sat, 21 Mar 2020 19:34:19 GMT View Forum Message <> Reply to Message plasmo wrote on Sat, 21 March 2020 11:12I like to hear applications that can use memory more than 16meg. Emacs and gcc both immediately come to mind. 8)

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikemac on Sat, 21 Mar 2020 21:59:22 GMT View Forum Message <> Reply to Message mikesmith wrote on Sat, 21 March 2020 12:34plasmo wrote on Sat, 21 March 2020 11:12I like to hear applications that can use memory more than 16meg. Emacs and gcc both immediately come to mind. 8)

I didn't know either one of those run under CPM68k. :twisted:

My old Sun3 only had 16MB and it ran Xemacs, X11, and gcc at the same time under SunOS.

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Sat, 21 Mar 2020 22:18:23 GMT View Forum Message <> Reply to Message Hi Bill,

I'd like to purchase a 68012, but I couldn't find one in any of the usual places. Any advice on where I could find one?

Thanks Regards, Rosario

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 22 Mar 2020 01:29:25 GMT View Forum Message <> Reply to Message rvumbaca wrote on Sat, 21 March 2020 16:18Hi Bill,

I'd like to purchase a 68012, but I couldn't find one in any of the usual places. Any advice on where I could find one?

Thanks Regards,

Page 80 of 82 ---- Generated from RetroBrew Computers Forum Rosario Rosario, There was a discussion about MC68012 on Google group comp.sys.m68k. Bruce Mardle has quite a number of them, so I offered to buy a couple, but he sent them to me free instead. I returned the favor by sending him two populated MB012 boards. I was not able to find another source for MC68012, either. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Sun, 22 Mar 2020 01:47:14 GMT View Forum Message <> Reply to Message mikesmith wrote on Sat, 21 March 2020 13:34plasmo wrote on Sat, 21 March 2020 11:12I like to hear applications that can use memory more than 16meg. Emacs and gcc both immediately come to mind. 8)

MicroEMACS (ME.68K) is installed on Tiny68K. Since TPA is about 7 meg, I can in theory edit a 7 meg document in CP/M68K, but the time to load and save document is much too long to be useful. 8 meg of Tiny68K's 16 meg memory is a set aside as a 8meg RAM disk in CP/M68K. At one time I thought running programs out of RAM disk would be faster, which is in fact true, but the time to load programs into RAM disk is too long to be actual useful. So my conclusion is 16 meg memory for 8MHz or even 12MHz 68000 is too much, at least for CP/M68K applications. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by rvumbaca on Sun, 22 Mar 2020 21:19:28 GMT View Forum Message <> Reply to Message Hi Bill, plasmo wrote on Sat, 21 March 2020 18:29] There was a discussion about MC68012 on Google group comp.sys.m68k. Bruce Mardle has quite a number of them, so I offered to buy a couple, but he sent them to me free instead. I returned the favor by sending him two populated MB012 boards. I was not able to find another source for MC68012, either.

Ah, well I guess since the upper address lines of the 68012 are not being used, one might as well use a PGA 68000 (or PGA 68010) on the MB012 :)

Regards,

Rosario

Page 81 of 82 ---- Generated from RetroBrew Computers Forum Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by plasmo on Mon, 23 Mar 2020 04:23:46 GMT View Forum Message <> Reply to Message I have tried both 68000 PGA and 68HC000 PGA on MB012 and both work. The 68HC000 is rated at 12MHz, but seems to work just fine at 16MHz. I don't have 68010 PGA, but I expect it to work. Bill

Subject: Re: Tiny68K, 68000 SBC with 16 Meg memory for CP/M-68K Posted by mikesmith on Wed, 25 Mar 2020 06:29:12 GMT View Forum Message <> Reply to Message mikemac wrote on Sat, 21 March 2020 14:59mikesmith wrote on Sat, 21 March 2020 12:34plasmo wrote on Sat, 21 March 2020 11:12I like to hear applications that can use memory more than 16meg. Emacs and gcc both immediately come to mind. 8)

I didn't know either one of those run under CPM68k. :twisted:

My old Sun3 only had 16MB and it ran Xemacs, X11, and gcc at the same time under SunOS. It would not be terribly hard to get temacs up and running. Dumping to generate a 'real' (read: usable) emacs would probably mean a bit more ugly, but still quite doable.

I believe it builds and runs under MiNT and probably emuTOS, which are a bit more of a stretch but still eminently possible...

Page 82 of 82 ---- Generated from RetroBrew Computers Forum