Z-Berry: Z-80 computer
sites.google.com
sites.google.com
Not to be pedantic, but the Timex Sinclair 1000 of 1981 had a lower chip count than this computer.
Take a look at the board: http://oldcomputers.net/pics/ZX81-mb.jpg
And it even includes the RF modulator.
Of course, the Z-berry is a far more powerful Z80 computer.
Ready to run again all your CP/M 80 programs?
PS: What would have RULED would be to include in the Z-Berry a socket for the SID* sound chip or at the very least two POKEY* chips.
* SID: Commodore 64 sound chip. POKEY: Atari 8-bit (800/400/800XL/etc) sound chip.
https://en.wikipedia.org/wiki/S1_MP3_player
The econet system too, this time with email and web access but still the hackable LAN that was so much fun to navigate and spoof.
?&D22=100 to change my station number to the IT teachers station when he'd left for the day. Thus all logs were from his machine, seemingly.
He hated me and my mate. To the point where he had spooled all system privileged activity to actually print out (not to a text file, he wasn't the smartest even to us 14 year olds) to paper.
It was his genius plan to narrow down which room we were logging into from!
The next day we see a locksmith changing the locks to his private computer room.
He never did catch us. Someone snitched in the end. We told a friend who boasted unbeknownst to us to others and the jig was up.
Banned from computers for the rest of school.
A really cool science teacher got us involved with the weather station (it recorded data from NOAA sats to the BBC micro!!) so got the ban amended to 'no computers with network access' so we could use the computer in his lab.
Of course we then learned how to splice cables and made a reeeeeally long econet cable and had a system of lookouts.
Good times.
Thanks Mr. Bush you were a good guy who nurtured our interest. AS for you Mr. Pollard, as an adult I get why you hated us but still, if you'd have asked us to help with the network or the lab or something we could have avoided our war.
Sorry guys, big barely relevant anecdote but hopefully someone else will smile at the fun days of the BBC Micro and remember the econet hacks.
I designed a and built new I/O extender to fix all those problems but PCB design is not fun for me so I never made a PCB for it.
This one looks to have none of those problems.
If not then good luck writing code to page out to that 512k of RAM. I do wonder what the 1980 computer scene would have been like if 512k was there because that was the smallest amount available, instead of the normal 16k. It was only when the PC came along that this amount of memory was available. PC programs took a while to be as concisely optimised as home computer code had to be. So maybe the scarcity of RAM was a good thing.
http://chrisacorns.computinghistory.org.uk/8bit_Upgrades/Sol...
I used it for very limited black-and-white 3D animations, pre-compute the edges, then draw the images in real time and for other tricks.
A few months ago when trying to interface a bunch of hardware to a PC I realized how much easier such tasks were in the past, it's funny how we have made it much harder to expand a computer in our own domains (electronics, interface boards, standard ports with immediately usable i/o almost without latency) compared to how much easier it is to expand a computer towards the domains of others (networking).
I used it quite a lot when I got a bit older - the RAM disc's speed made it very useful. Good to play disc Elite (once unprotected...) from, and I remember it being much quicker to assemble stuff with ADE.
(I still have it, but the Opus EPROM erased itself long ago, so the RAM disc part has languished unused for a very long time. The 32 year old disc drive still works fine with my Master 128 though...)
You probably could re-program that EPROM if you wanted, or replace it with a ROM so you won't have that problem ever again. But this is probably not the most practical system for today :)
Unfortunately I lost almost everything I ever wrote for 8 bit platforms and a lot of my early PC and Atari stuff. It's a real pity, but then again, it also forced me to cut ties with the past and move on which in a way was a blessing.
But it would have been nice to open up a lifetime of code at some point.
(Yes, this is so convoluted, and so unusable, that it basically reinforces, rather than refutes, your point.)
[1] http://elks.sourceforge.net/
[2] http://elinux.org/images/6/68/Porting_uClinux_CELF2008_Griff...
However, microcontrollers and game systems have been using more than 64k with it for ages now. It's all done with bank switching. https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:z-... explains how Z-Berry does its bank switching.
To get real protection of programs against other programs and of the kernel against any programs you would have to make the bank switching logic privileged, but I would think that's doable with some external logic that snoops the memory bus and only allows switching to another bank if either the current bank is bank zero or the destination bank is bank zero and the instruction pointer matches that of the kernel's entry point.
You also would have to force a switch to bank zero to preempt processes. I think the easiest approach would be a timer that, when it expires, switches to bank zero and interrupts the CPU.
With this hardware, that could give you 7 processes, max. I think you could have fun with a minimal Unixlike OS in that.
Edit: it will be a bit of a challenge to pass arguments to the kernel if the kernel can't rely on hitting trusted code when it bank-switches back to a process to, say, read a memory buffer, but that can probably be overcome by force-mapping, say, the last kB of RAM to the kernel's memory space.
As far as what it was used for - people mainly used it for RAM disks; it could also be used for page-flipping for the higher-res graphics modes the CoCo 3 supported.
For the OS-9 Level II operating system, it was used much more efficiently to allow for larger (or more) programs to be multi-tasked, along with other uses.
(for those unaware - OS-9 was a multi-user, multi-tasking operating system for the 6809 and other 8-bit microprocessors of the day - but mainly geared to Motorola CPUs - including later the 68k family)
Also: https://github.com/nealcrook/multicomp6809/wiki
and finally: https://www.retrobrewcomputers.org/doku.php for more retro goodness.
You could go two ways:
1. Have some amount of RAM outside the bank switching scheme so code and data living there is always available and bank switch above or below that fixed area.
2. Switch the entire 64k at a time, meaning your code and data has to be copied into the same place in each bank.
Much cooler (imho) is http://symbos.de/ though, also for z80 machines.
Too bad that you can't order one pre built. I'm not competent enough to solder that.
If you want to go full retro, x86 is relatively difficult due to the support circuitry needed. Full ISA, ram, ports, etc. PCs were fairly complex machines back in the day.
I recall using a PROLOG interpreter on a Kaypro II under CP/M. Worked neat.
Also i used an ALGOL-60 compiler. In fact, just a subset of ALGOL-60. So, in some ways, a limited subset of a subset of Pascal.