OMU on the pPropQL
Ale
Posts: 2,363
Well,
as many may know I'm porting One Man Unix to the pPropQL. Actually only 2 boards exist so the audience is a bit limited. I also have to write the io and video to make the QL ROM run in these boards, but that is also a work in progress.
Hardware:
a 68008 processor
128k (minimum) SRAM
64/128k FLASH/EPROM
2 Propellers one for video and one for IO
I'm not planning to do more pPropQL board as they are because there is a lack of 68008 processors. But as I have some 68EC020 available they can be used (with a new PCB) instead, even in 8 bit mode (low cost/simplicity solution). If you want a board, ask for one of those.
I have a new board in the making, currently in production now with a 68EC020 but with 32 bit bus. If all goes well, it will be ready in two weeks. If anybody wants one let me know so I can launch a new series (I let only 2 be made). (Baggers I did not forget you).
This new board can also run uClinux if it is stripped enough. I has basically the same hardware as the other one but with more ram, a faster processor, a peripheral expansion bus, and programmable logic.
***
Now, the porting of OMU:
- As I do not know the availability of the original compiler and some missing include files, I'm using gcc targeted to m68k.
- Missing includes: I borrowed some (and modified) linux headers. This gave a bit of extra complications but well, you cannot have everything. They are mostly solved now.
- The kernel compiles but some device drivers not. To address this I rewrote a harddisk driver (to use a SD card) and have still to write a new tty, extra serial and rtc drivers. The original SCSI and floppy drivers were dropped. The ramdisk remains for now, it compiles.
- Binary interface. The original OMU used a kind of a.out format. We could either use some other (maybe the same, by chance) a.out format or directly elf. I think elf poses some extra overhead and complications unnecessary at this point.
- Disk format. It uses some sort of UDF, may or may not be compatible with any linux supported UDF. I'd leave it as it is because I want it to boot before I touch it too much.
- The original needed some 256k RAM, but I want it to work on 192k so pPropQL can be used. This board can be with small modifications be adapted to use 640k RAM albeit not contiguous (I think the lower 128k can be safely used for video and kernel and the rest for programs).
- The lack of (as of yet) a native compiler (some exist but it will be in the not so near future) compilation means cross-compilation. Linux works now, Mac OSX comes next, winblows at your own risk, as always.
Note: with 4MB in the 020 board, uClinux can be safely used. But there are little challenges in that path
.
as many may know I'm porting One Man Unix to the pPropQL. Actually only 2 boards exist so the audience is a bit limited. I also have to write the io and video to make the QL ROM run in these boards, but that is also a work in progress.
Hardware:
a 68008 processor
128k (minimum) SRAM
64/128k FLASH/EPROM
2 Propellers one for video and one for IO
I'm not planning to do more pPropQL board as they are because there is a lack of 68008 processors. But as I have some 68EC020 available they can be used (with a new PCB) instead, even in 8 bit mode (low cost/simplicity solution). If you want a board, ask for one of those.
I have a new board in the making, currently in production now with a 68EC020 but with 32 bit bus. If all goes well, it will be ready in two weeks. If anybody wants one let me know so I can launch a new series (I let only 2 be made). (Baggers I did not forget you).
This new board can also run uClinux if it is stripped enough. I has basically the same hardware as the other one but with more ram, a faster processor, a peripheral expansion bus, and programmable logic.
***
Now, the porting of OMU:
- As I do not know the availability of the original compiler and some missing include files, I'm using gcc targeted to m68k.
- Missing includes: I borrowed some (and modified) linux headers. This gave a bit of extra complications but well, you cannot have everything. They are mostly solved now.
- The kernel compiles but some device drivers not. To address this I rewrote a harddisk driver (to use a SD card) and have still to write a new tty, extra serial and rtc drivers. The original SCSI and floppy drivers were dropped. The ramdisk remains for now, it compiles.
- Binary interface. The original OMU used a kind of a.out format. We could either use some other (maybe the same, by chance) a.out format or directly elf. I think elf poses some extra overhead and complications unnecessary at this point.
- Disk format. It uses some sort of UDF, may or may not be compatible with any linux supported UDF. I'd leave it as it is because I want it to boot before I touch it too much.
- The original needed some 256k RAM, but I want it to work on 192k so pPropQL can be used. This board can be with small modifications be adapted to use 640k RAM albeit not contiguous (I think the lower 128k can be safely used for video and kernel and the rest for programs).
- The lack of (as of yet) a native compiler (some exist but it will be in the not so near future) compilation means cross-compilation. Linux works now, Mac OSX comes next, winblows at your own risk, as always.
Note: with 4MB in the 020 board, uClinux can be safely used. But there are little challenges in that path
.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Did you manage to contact Steve Hosgood about OMU?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater: the props do not execute linux, they only do I/O. While they do have the horsepower they do not have the memory capabilities :-(. I hope they fix that for next prop !
I remember running mklinux on my 68020 Mac IIci years ago (I had the add-on MMU)... ucLinux looks like fun. I wonder if I can get the m68k Freepascal compiler to compile bstc ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
That would be very nice!
There are plenty of warnings during compilations and lodas of redefined symbols and I need a useful simulator to test all this. That will be the next point: get it to run in a simulator.
TODO:
- Eliminate warnings and duplicated symbols
- Implement some libc functions
- Get the binary to start at 0x00_0400 instead of 0x8000_0000 :-(
- Get it to run in a simulator
Propeller tasks:
- Implement the tty
- Implement low-level SD access
- Implement keyboard
- Implement text video
- Fun at 14:00 16:00 and 20:00 hs
If anyone wants to give it a try, let me know so I post the current source.
What would we run it on ???? [noparse];)[/noparse]
.. oh and *well done*!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised!
I think you are missing the point here
Why there is no simulator that suit my needs ?
I have mentioned from time to time how I'd like an ARM or such running Linux and a prop or two on a small board. This is just the thing.
Good to here about OMU.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I'm working of the propeller interface for SD card so I can finish the bootloader and the hardware device driver for OMU. The serial tty is going to be implemented using the video propeller and the keyboard. A serial port will also be implemented.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
- I finished the SD interface, i.e. I can read sectors from the Moto processor at will. A nasty hardware bug (NWE0..3 were reversed!) was preventing further progress.
- The circular buffer in the keyboard object is driving me crazy. So I put it to rest for a while
- I settled on a minix v2 filesystem either in a FAT partition or as a partition itself, to be determined, not very important at the time.
- A java based M68k simulator has been obtained, I wrote a disassembler for it and it works. There are a few missing opcodes but it should be enough (with the added opcodes) to debug OMU. It does not contain any 020 specific opcodes, OMU and the simulator but it shouldn't be a problem. A small interface for console, SD card, RTC and keyboard has (still) to be written.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU