There is a running CP/M-68 in the mini-68K folder (ECB design). Serial I/O would be different, but most of the code will probably be portable. It is written in C, and compiles with the GCC cross-compiler running on Windows.
On 03/10/2013 10:16 AM, yoda wrote:Hi Andrew!!
I am surprised at the resistance to the PLCC - I find the DIP-64 much more fragile and takes up a whole lot more space than the PLCC 68 footprint. I would really like to get to the AT1024 style eeprom for the ROM as well. I find having to pull and program 2 chips much more time consuming than 1 and there is really no way to put ZIF sockets on the current board. I have started developing my code on the MC68360 board we have designed because it only has a single chip eeprom and I can put a ZIF socket in for it - makes rapid changes a lot easier. With my current work I am trying to develop the monitor and CBIOS for CP/M 68K all in C with very minimal assembler code required - mainly for initializing the Data, BSS and stack (requires a little more assembler on the 68360 as there is some initial work in getting the memory setup to be used here but on the S100-68K you basically only need to set up stack pointer and copy data and BSS from ROM to RAM and then jump to C). My overall goal here is to have code that is platform independent that can be completely reused between the 2 platforms.
I am not sure what a 68020 is going to buy other than it can be done. There is no on chip MMU or FPU. The advantage of a 68020 would be it has a full 32 bit data bus but that is not very useful in an S100 system as the bus only supports 16 bit data at best.
On Sunday, March 10, 2013 9:35:39 AM UTC-5, lynchaj wrote:
Hi Dave! Thanks! We did convert the S-100 68K V2 prototype to the PLCC and although it worked there was a lot of push back on the design. I think a lot of builders just like the DIP-64 package I guess. Good point on the 16 bit Flash though.
The major cause of the recent delay of the S-100 68K CPU V3 board is I completely reworked the PCB layout. Originally the chips were vertically oriented and it drove the trace route optimizer nuts. I reoriented everything to horizontal and it literally cut the number of vias in half and reduced trace length by a large percentage. Probably I should have done that at the beginning though but I was trying to retain as much compatibility with the original design as possible but that’s fallen away too.
Once we get the S-100 68K CPU board out though I do have plans to add in a MC68020 CPU shim board based on a C’T Projekt design. I forget the name at the moment but have all the plans here at the ready.
It seems that of all the S-100 boards, the CPU designs are the most difficult and cause the most rework. That’s the bulk of the backlog at the moment: S-100 80286 CPU, S-100 68K V3, S-100 6502 V2, S-100 80386 CPU + SRAM, etc. It’s a bit like a python that just ate 4 goats in a row. It is taking a while for all the lumps to work through the system J
Thanks and have a nice day!
You received this message because you are subscribed to the Google Groups "N8VEM-S100" group.
To unsubscribe from this group and stop receiving emails from it, send an email to n8vem-s100+...@
For more options, visit https://groups.google.com/