Toby - CPLD I havent played with yet amazing ly enogh in 30yrs of elec des. Jst one of those things - I recently got some and a programmer (Altera)
its my Sunday afternoon treat to hook a few lins up and have a play. Im a bit of a Nascom fanatic myself - or when I get the time In facat anything z80 based (or not acroding to the other half). I have exampe of z80 from the Hitachi ?16MHz chip used in the Sharp Zuarus range - the NSC?800 used in the Husky Hunter, and a few more esotoeric ones. The Microcontroller used in the Thorn EMI Liberator I have miught interset you its some sort of earyl PIC sort of thing eith piggybackes EPROM. Oh the SRAM is piggyback socketed as well.
Once fixed I plugged in some of the non-volatile memory backup cartridges - last used in 1988 to store
text files - the cartridges are just ram with a coin cell battery.
Every single cartridge has all its data intact after 27 years running on a single 2032 cell. The manual says change every six months
Hi Drac -
most of the probs I see comeing from using microcontrollers to do these sort of things come down to - of course - the video. Im no averse to putting in an extra PIC or Prop just to get things runing smoothly - its all a bit 'tight' on one prop/z80.
In my case I'm transferring the problem onto a bridge onto the ISA bus - to drive VGA cards/NET /SCSI etc. howvere I do want to still do a 'simple; solution using a microcontroller to
provide the original basic Lynx video (or mor e mordern VGA output). I've been looking at the work done on PICs using the SPI output to drive VGA displys at rates highesr than is usually possible in PICs.
here's a thought that's been bugging around my head for some time - is there any benefit in shadowing the VRAM betwweeen the z80 side and the video.
i.e. let the z80 (in my case the Lynx or Spectrum C64 etc) talk to one set of VRam (as in the Lynx case is does several read/writes to ajust or overwriting etc) and yet push writes ONLY through to another set of VRAM (or just the Prop). The Prop then has its own timescale to read out the VRAM. In my case he oringal computer will be running at several times the origninal speed to accurate framerate isnt really n issue for me.
1. do wegain nytnig by it being always a 'write' case from the prop perspective
2. by havig the second VRAM availeble to the prop/dspic it can spend whatever tiem it likes - inclding messing with the z80 clock - oinorder to provide the tv/vga picture.
Sorry I dhoulf also say that my 1st machine is the Lynx though - as afar as \im aware the last machine to have a monitor in rom? what really interests me is its bank switching - there's no window -the whole bank switches - I cant think of another 80s home comp. z80 which does this. Althogh at the tie the graphics (albeit the best avilable before the 16biti or perhaps Enterprise Elan tho that was prob post 16bit too, (and no I dont count the TI early QL cut down ) was seen as slow as is the case over the eyaasr the hackesrs got to it and its turned out to be very powerful system.
Oh dd someone mention 6809? I'm hoping to do dual here with a 63C09, end result is a dual Lynx / HH Tiger
not Selectronic then I can remember doing newsletters with them before the advent of DTP - started of as a Compositor when I was 16 - did Ventura form 1.0 on a 12MHz (oooo feel the Turbo power) 80286.
Anyone remember Wildcat BBS? the joy of runnning one and logging in to the command prompt - then forgetting and running some graphic editor and having to phone up to reboot
1/4 hour download of 40k Hercules demo Moire pattern anyone?
The Lynx has a BBS sstem which Im in process of getting on the net - also a friend who has an tcpip stack in the works.
oh quick ask - has anyone any idea where a copy of TRANS86 is to be had (part of ACT86 from Sircom), I have the docs, no sw after several hours of searching.
The Liberator. Fantastic I don't think I have ever heard of it before. 27 years data retention on a battery backed RAM is amazing. That makes it more reliable than most floppies or CDs.
I did some programming work on the Hunter. But it was the later Hunter 16, 8086 based MSDOS machine. (Well actually Hitachi V20 chip). The ones I worked on were hardened military versions in cast aluminium cases. Chemical proof and everything. They were kitted out with special modems for wireless data communication.
Anyone remember Wildcat BBS? the joy of runnning one and logging in to the command prompt - then forgetting and running some graphic editor and having to phone up to reboot
1/4 hour download of 40k Hercules demo Moire pattern anyone?
The Lynx has a BBS sstem which Im in process of getting on the net - also a friend who has an tcpip stack in the works.
I suppose I should give a very quick summary of the Lynx arch - its convetional - vry so - but with some very clever additions:
z80a/b 4/6 Mhz
one bank latch - read/write enables for 5 banks (ROM B0 takes priority over any read conflict)
Bank switch occurs for whole 64k space. ROM is aviale - but copying BASIC to 1st bank RAM speeds by 10% due to lackof waits.
note: bank contention is possible (ad very probable when dev), I dont know about the normal Lynx dram(w refresh) putting up with it but my Proto version with 1 chip modern SRAm comes back to life after a hunfre such episodes - someitmes i worked out success when chopping the addr dec. by number of mA down on the psu display.
one video latch - controls (omong other things) access to reading video DRAM, Output for 'freeze until Lineblank', Output for same for Frameblank.
6845 - access to 32k of ram (4896 - banks 2 & 3 16k from 8000h) or 64k(128) - 128 has 2x horizontal display to do CPM (also later done with 96 - aslo about to be done again by F.M. as CPM native for 4896 without 'hacks'). For 4896 one 8k bank is unusd usually by the video sys (alt. green). 8 colours are abail at any pix positon of 256x248 (or higher when tweaked)
Vid mem RGB is clocked from 3 segs of dram - 4896(bank 2 R/B from 8000-, bank 3 AG/G) or 128(bank2 RGB from 0-)
For 128 (and CPM) the lower 100h of 128 versin is duplicated across banks to allow crooss bank code continuation.
The code in this region is also heavilty self modified y the BASCI OS in order to generate the many graphical efects. In particular the PROTECT command can inhibit wriitng to any combo of banks this speeding display and allowing overlays etc. This was used to good effect when cramming in the level9 seres of adventures - the RB banks were used to store 16k of advent data which flashed onscreen when the Lynx was 'thinking' between moves. nostalgia...
48k - 16k rom B0 - 16k dram B1 User - 16kdram B2 R/B - 16kdram B3 AG/G
96k - 24k rom B0 - 64k dram B1 User - 16kdram B2 R/B - 16kdram B3 AG/G
128k - 24k rom B0 - 64k dram B1 User - 64k dram B2 RGB
192k/256k never released by Camputers - but made in 2012 by Frank Rasmussen.
oh quick ask - has anyone any idea where a copy of TRANS86 is to be had (part of ACT86 from Sircom), I have the docs, no sw after several hours of searching.
oh, there's also some footage of the Liberator on the channel - the contrast on the screen is so poor its impossible to video. I'm tryig to track down the schematics in order to improve on the hv driver side of things.
oh btw, I think I used your ZiCog in the Spectrum Emu i did for the Chameleon years ago - must dig out the source sometime to see if I can imrpove the speed.
Given the ease of use etc. and great data renent (which they prob didnt know about at the time - 27 years!!!) I cant understand why we all used awful floppies fro the next 20 years
From the tons of sw i've had through donations etc. I have a few opinions on 'firmishware'.
floppies - the 5 1/4 not so bad - as long as good quality and not Wabash, the 3 1/2 seem to hold moisture in more and most of the ones I get that have been 'attic or shed' stored are useless (or worse than).
Tapes - pretty reliable - apart from zx81 ( I've had some success with reading from the backside of the tape when the oxid is toopoor.
CDs - hmmm - tbh a few of mine are a bit flakey after 10 yrs so I hate to think what theyd be like 3 times that.
Core Memory - I have some from a Wang calc from 1957 - are the last calculations are stored in this memory?
And yes, one of my first investigations into Hunter programming was the POWER ON RESUME
note to self - do not code infinite loops when you have to take 30 odd machine screws out to reset the internal CMOS
Like the Liberator - a great piece of design - the Liberator is almost futuristic (though if I showed you some of the internal fit of early non-CAD moulding you'd realise why most photos look like Morris Marina panel fittings on a Friday with the Rovers playing at home. The main pcb is about 2mm too long for the case for example, and the port holes are a good 5mm to one side.
Despite this - it absolutely brilliant. Some of the wikiped is wrong - its not an fpga, and its more like the Hunter on batteries - 40hrs++ with AAs
I like the Husky because of the boot Logo - uncannily like the Lynx Pawprint.
Please have a try of my emujlator - its quite useful for things non Lynx related.
It the Lynx that you refer to the same one that had something to do with Nascom? I think that there was some sort of tie up at some time, along with Lucus, just as it all went **** up.
The CPLD will be a Xilinx XC9572 PLCC84, because I have some - and it all seems about the right "retro-ness". I have a few of Altera EPM7128's but all surface mount, they are OK for the final version, not for the half dozen trial ones! I do like the Altera software better but I can get by with ISE (on simple stuff like CPLDs). I harbour dreams of being intelligent enough to tackle some ancient FPGAs at some point as I have some old Cyclone ones to steam off.
As for the electric pulses ... I have to go for for a head MRI soon ... I am going to be EMC tested too!!
@ Dr_A
On CP/M what is the usual (if there is one) way to bank switch? Is there a normal amount to be switched? and from a normal address?
I am putting together a CP/M board from old bits (as usual) and as there is a 128KB ROM (only 8KB needed at boot) and a 128KB RAM it seemed a bit of a waste not to use the other bits of memory. I have a CPLD for glue so the map could be changed, if and when I know what I am doing!
Just to make things a bit more of a challenge Grant Searle's site is down for the second day :-(
I am putting together a CP/M board from old bits (as usual) and as there is a 128KB ROM (only 8KB needed at boot) and a 128KB RAM it seemed a bit of a waste not to use the other bits of memory. I have a CPLD for glue so the map could be changed, if and when I know what I am doing!
Just to make things a bit more of a challenge Grant Searle's site is down for the second day :-(
In your case, with a larger than real life ROM, the same trick would be required for the ROM as well.
Or take a hit on the ROM size in return for simplicity?
On CP/M what is the usual (if there is one) way to bank switch? Is there a normal amount to be switched? and from a normal address?
Bank switching can mess with your head!
Perhaps the simplest is the N8VEM. Blocks of 32k that you can switch in and out. That works well for ram disks. However it may not be the most optimal for variants of CP/M. I don't think CP/M 2.2 uses bank switching, but if you go to MP/M, you need to put the operating system in high memory, try to get it as small as possible, and then grow the memory down from the top. So in practice, you start writing code and every now and then you run out of space and so add another 2k. I think I got MP/M into about 12k. Or you can put 16k at top for the operating system and 48k for the programs. Of course, once you start writing programs in C or Basic or Fortran or Pascal, you want as much room as possible for your code, so there is motivation to make 48k a bit bigger. Or (crazy idea), move the entire operating system into another bank and have 64k available for your program.
So you have to decide how big to make the banks - 32k, 16k, 2k or something else.
Smaller bank blocks are the most efficient in terms of least wastage of ram, but need more driver logic.
I've even pondered crazy ideas, like taking 512k of ram, chopping it up into 2k blocks and any block can be mapped to any location, and then use another (smaller) ram chip to do that mapping.
But CPLD is another great way to go, because glue logic for banked memory can become quite complex.
The idea I'd like to explore is what I am going to call 'propeller bank mapping' and it has very little hardware as each 64k block is independent. I don't think this was ever done in old computers, because how would you jump between the blocks without a common block of memory between banks? But with a propeller chip, the Z80 can pass data between blocks by sending some data to the propeller, then send a message to shut itself down, then the propeller can stop the clock, change the memory bank, do a reset, restart the Z80 and move the data back into the new block. All untested as yet, but I think it should work.
I've even pondered crazy ideas, like taking 512k of ram, chopping it up into 2k blocks and any block can be mapped to any location, and then use another (smaller) ram chip to do that mapping.
Dr_Acula
I'm not sure if you are aware, but you'd just described an amazing way to do some kind of totaly re-configurable, patchwork style memory mapping!
It can be simultaneously a bless and a mess to deal with, specially having in mind the way relative jumps across page boundaries would work in the such a Propeller/Z80 realm.
I suspect, just a shallow glimpse of my own thoughts, that some kind of prefix should be added to the existing Z80's address referencing instruction subset coding, to actually deal with such a scheme.
Even if we must recur to the old Define Byte or Word code insertion, it will be a total fun.
Oh boy, it can become an addicting way of big stuff coding, using Propellers and Z80s together!
I'm not sure if you are aware, but you'd just described an amazing way to do some kind of totaly re-configurable, patchwork style memory mapping!
He he. It sure can get confusing. I'll explain it a bit more - mainly so I understand it
Ok, simple bank switch as used in the N8VEM - 32k blocks and you have one latch and if A15 is low then it always addresses the lowest 32k, and if A15 is high then the latch selects the block (eg for 512k there would be 16 blocks of 32k so you need a latch with 4 bits). You could add a second latch, and map the lower 32k as well. But each time you add more bits (ie smaller blocks) , you need more latches and it gets impractical very quickly.
A second small ram chip solves the problem (in this case, 256 bytes of memory).
Consider 512k of ram with A0 to A18. A0 to A10 go into the ram chip from the Z80 and that is 2k. Z80 A11 to A18 go into the address lines (A0-A7) of a small ram chip, and then the D0-D7 of that ram chip go to A11-A18 of the 512k ram chip.
The small ram chip replaces lots of latches, and may well end up simpler than a CPLD as well.
2k blocks of memory, mixed up in any way you want them.
The challenge, and I haven't worked this out yet - how do you program that small ram chip with the least number of glue chips?
It may be CPLD can do this. So - CPLD vs some glue chips and a small ram chip.
" I don't think this was ever done in old computers, because how would you jump between the blocks without a common block of memory between banks?"
This is the scheme used by the Lynx - full 64k bank switching - as far as I'm aware its unique for a home comp. You just have to make sure that the code context carries on across the switch by duplicating code in others banks. It can get complicated
Although the whole 64k gets switched the ROM in Bank 0 is given priority on reads below the 24k boundary (and above E000 where the ROM for the Disk OS sits) in situations where multiple banks are selected for reading thus giving the 'common ground' you mention. So in general you would copy some ROM code off to another bank, then switch out the ROM and move the context into the new bank.
As an example, to print a character from CPM (in Bank 1) the PC moves into the E000 area (which is a duplicate of the ROM) and then the RAM is switched out and ROM switched in - context is now in Bank 0. The graphics output is in the Lower 100h bytes of ROM which is duplicated across to Bank 2 (Video RAM). Context is then switched across into the Video bank RAM and writing the screen occurs. Then the reverse sequence of switching occurs again to get back to Bank 1 and continue CPM.
So even for CPM 2.2 on the Lynx theres a lot of bank switching going on. The attached shows the Banks 0 1 2 layout for CPM running on the Lynx.
The CPLD I am going to use is only a 72 macro job so too much fanciness wont happen.
It is my ancient past where a 2K x 8 SRAM was " Ooooh.... shiney!" and half a dozen people stood motionless, pointing. So to kiss goodby to 64K SRAM and 96K EPROM seems a crime. I will have to get it working on CP/M 2.2 first then try for 3+ :-)
This is the scheme used by the Lynx - full 64k bank switching - as far as I'm aware its unique for a home comp. You just have to make sure that the code context carries on across the switch by duplicating code in others banks.
Brilliant! This sounds like something we could replicate for the propeller. It should be easy to duplicate the code - that could be done at startup with a small library of common code in the same location in each 64k.
The bank latch (pictured on the RHS) is a simple set of bits for R/W control, you can select multiple banks for read or write (its programmers responsibillity to avoid bus contention). So a transfer fro m one bank to another is setting up the Read/Write bits on the latch and then copying using ldir.
as I write its 2013 and I'm sitting here soldering up a CPLD to an ISA passive backplane - great days
To give you an idea of my madness I'm contemplating
a CPU upgrade for my project with a Prop running four or five processors - z80, 6309, 68008, 6502 and V30 - each able to
access the Lynx main memory on a basis similar to the Prop hub.
Todays Sram upgrade along with a couple of rejiggings to eh decode has jumped the Lynx from 128 to 768k - its very extendable.
At present I'm going ahead with my Lynx - CPLD - ISA - VGA idea at the moment. I've looked around at some dsPic - VGA things but they're too much 'on the edge' and not enough res/colours. The closest I can see is baggers Spectrum emu running on the dracblade(?) - is the whole of the speccy memory (inc vidram) external?
I'm not sure the muxed adressing schemes would scale when I shift the z80 speed up to 20mhz? If anything I'd probably use the one prop just for VGA output and as many pins as poss for the memory access.
...a CPU upgrade for my project with a Prop running four or five processors - z80, 6309, 68008, 6502 and V30
That sounds a pretty cool upgrade!
VGA on the Propeller looks great when you first see it - a little chip doing text and graphics, but the 32k hub ram does have limitations with graphics. A VGA card with an ISA bus sounds intriguing. I looked up the ISA bus specs and it looks like something to explore further. Reaching back into my memory banks of the past, were early VGA cards about 1mb of memory? If so, you do get a lot more options than with 32k of memory.
I'll get together a list of the connections I made, see if anyone can spot some gotchas.
peter
Oh btw Dr_A - I think the Morpheus drivers may be able to do what I want (for the simple Lynx output case) - do you know if theres a list of what drivers are available for the board? I'm looking for 256x256x8 and 512x256x8.
For 10MHz you might be able to generate if the combination of the "waitpeq" and "and outa, mask" operations can complete within 6 clocks after the edge.
FWIW, after a pin change waitpxx has an exit path of 3 cycles. Which suggests that you won't meet your 6 cycle requirement here.
There is a 3 cycle solution for this (wait-after-cs) as opposed to the 7 cycles from waitpxx/andn.
Thanks kuroneko. I'm getting some boards made (my first 4 layer PCB) and when this arrives I'll be able to test your code. This circuit has more chips than a bare bones Z80 and propeller hybrid, but it has the N8VEM ECB connector which allows all the N8VEM boards to be added. I think it is worth the extra chips to be able to work to a common 'standard'.
This project has been kind of rendered obsolete by the fpga revolution. Prices keep falling, power consumption goes down and pin count goes up. It is all good!
But what he didn't do is give you the working code. He makes you put it together step by step, and in doing so, teaches the basics of VHDL.
The final product is an emulation running about 10x faster than the best propeller emulation, for about the same cost. There may be scope here for a propeller/fpga hybrid. Though the way fpga chips are falling in price, there may also be scope for a propeller emulation within the fpga. Today's cutting edge chip seems to be tomorrow's retro emulation.
I feel a fpga/propeller hybrid coming on. There are a few things that the propeller may do better - audio, and handling multiple complex tasks in parallel. I wonder how minimalist a propeller circuit could be? Replace the xtal with a clock from the fpga board? Replace the eeprom with an emulation of an F10 download?
Yes, hookup power and bypass, provide a clock from FPGA pin, hook another FPGA pin to reset, either simulate a load across P30 & 31 of have your FPGA look like an EEPROM on P28&29. All doable from Prop to Prop, should be doable from FPGA to Prop.
Comments
Toby - CPLD I havent played with yet amazing ly enogh in 30yrs of elec des. Jst one of those things - I recently got some and a programmer (Altera)
its my Sunday afternoon treat to hook a few lins up and have a play. Im a bit of a Nascom fanatic myself - or when I get the time
http://www.youtube.com/watch?v=vmar-PSCejQ&feature=youtu.be
Once fixed I plugged in some of the non-volatile memory backup cartridges - last used in 1988 to store
text files - the cartridges are just ram with a coin cell battery.
Every single cartridge has all its data intact after 27 years running on a single 2032 cell. The manual says change every six months
Hi Drac -
most of the probs I see comeing from using microcontrollers to do these sort of things come down to - of course - the video. Im no averse to putting in an extra PIC or Prop just to get things runing smoothly - its all a bit 'tight' on one prop/z80.
In my case I'm transferring the problem onto a bridge onto the ISA bus - to drive VGA cards/NET /SCSI etc. howvere I do want to still do a 'simple; solution using a microcontroller to
provide the original basic Lynx video (or mor e mordern VGA output). I've been looking at the work done on PICs using the SPI output to drive VGA displys at rates highesr than is usually possible in PICs.
here's a thought that's been bugging around my head for some time - is there any benefit in shadowing the VRAM betwweeen the z80 side and the video.
i.e. let the z80 (in my case the Lynx or Spectrum C64 etc) talk to one set of VRam (as in the Lynx case is does several read/writes to ajust or overwriting etc) and yet push writes ONLY through to another set of VRAM (or just the Prop). The Prop then has its own timescale to read out the VRAM. In my case he oringal computer will be running at several times the origninal speed to accurate framerate isnt really n issue for me.
1. do wegain nytnig by it being always a 'write' case from the prop perspective
2. by havig the second VRAM availeble to the prop/dspic it can spend whatever tiem it likes - inclding messing with the z80 clock - oinorder to provide the tv/vga picture.
will write more when jhouse in better state.
BRegs
Peter
Here's the most interesting Z80 machine I like the Thorn EMI Liberator.
i hope the pixturea come out with being a new postesr, Im sorry I dont know if its etiqete to post inline but they zre prety dmall
If anybody knows Carmarthen im off there on Wednesday to hav my arm wired for sound (or eletricil impulses laxk thereof)
br
peter
Oh dd someone mention 6809? I'm hoping to do dual here with a 63C09, end result is a dual Lynx / HH Tiger
Peter
1/4 hour download of 40k Hercules demo Moire pattern anyone?
The Lynx has a BBS sstem which Im in process of getting on the net - also a friend who has an tcpip stack in the works.
oh quick ask - has anyone any idea where a copy of TRANS86 is to be had (part of ACT86 from Sircom), I have the docs, no sw after several hours of searching.
Pete
The Liberator. Fantastic I don't think I have ever heard of it before. 27 years data retention on a battery backed RAM is amazing. That makes it more reliable than most floppies or CDs.
I did some programming work on the Hunter. But it was the later Hunter 16, 8086 based MSDOS machine. (Well actually Hitachi V20 chip). The ones I worked on were hardened military versions in cast aluminium cases. Chemical proof and everything. They were kitted out with special modems for wireless data communication.
1/4 hour download of 40k Hercules demo Moire pattern anyone?
The Lynx has a BBS sstem which Im in process of getting on the net - also a friend who has an tcpip stack in the works.
I suppose I should give a very quick summary of the Lynx arch - its convetional - vry so - but with some very clever additions:
z80a/b 4/6 Mhz
one bank latch - read/write enables for 5 banks (ROM B0 takes priority over any read conflict)
Bank switch occurs for whole 64k space. ROM is aviale - but copying BASIC to 1st bank RAM speeds by 10% due to lackof waits.
note: bank contention is possible (ad very probable when dev), I dont know about the normal Lynx dram(w refresh) putting up with it but my Proto version with 1 chip modern SRAm comes back to life after a hunfre such episodes - someitmes i worked out success when chopping the addr dec. by number of mA down on the psu display.
one video latch - controls (omong other things) access to reading video DRAM, Output for 'freeze until Lineblank', Output for same for Frameblank.
6845 - access to 32k of ram (4896 - banks 2 & 3 16k from 8000h) or 64k(128) - 128 has 2x horizontal display to do CPM (also later done with 96 - aslo about to be done again by F.M. as CPM native for 4896 without 'hacks'). For 4896 one 8k bank is unusd usually by the video sys (alt. green). 8 colours are abail at any pix positon of 256x248 (or higher when tweaked)
Vid mem RGB is clocked from 3 segs of dram - 4896(bank 2 R/B from 8000-, bank 3 AG/G) or 128(bank2 RGB from 0-)
For 128 (and CPM) the lower 100h of 128 versin is duplicated across banks to allow crooss bank code continuation.
The code in this region is also heavilty self modified y the BASCI OS in order to generate the many graphical efects. In particular the PROTECT command can inhibit wriitng to any combo of banks this speeding display and allowing overlays etc. This was used to good effect when cramming in the level9 seres of adventures - the RB banks were used to store 16k of advent data which flashed onscreen when the Lynx was 'thinking' between moves. nostalgia...
48k - 16k rom B0 - 16k dram B1 User - 16kdram B2 R/B - 16kdram B3 AG/G
96k - 24k rom B0 - 64k dram B1 User - 16kdram B2 R/B - 16kdram B3 AG/G
128k - 24k rom B0 - 64k dram B1 User - 64k dram B2 RGB
192k/256k never released by Camputers - but made in 2012 by Frank Rasmussen.
oh quick ask - has anyone any idea where a copy of TRANS86 is to be had (part of ACT86 from Sircom), I have the docs, no sw after several hours of searching.
Pete
The insides are a testament to 'no object spared' - just looking at the Serial connector makes me think of the pounds that went into waterproofing it.
The keyboard matrix do tend to give up the ghost though. I fixed mine by judicious use of a darning needle. A superb device all told.
http://www.youtube.com/channel/UCCa2b8ThIwUCbyQDOewNu2A
oh, there's also some footage of the Liberator on the channel - the contrast on the screen is so poor its impossible to video. I'm tryig to track down the schematics in order to improve on the hv driver side of things.
oh btw, I think I used your ZiCog in the Spectrum Emu i did for the Chameleon years ago - must dig out the source sometime to see if I can imrpove the speed.
Given the ease of use etc. and great data renent (which they prob didnt know about at the time - 27 years!!!) I cant understand why we all used awful floppies fro the next 20 years
floppies - the 5 1/4 not so bad - as long as good quality and not Wabash, the 3 1/2 seem to hold moisture in more and most of the ones I get that have been 'attic or shed' stored are useless (or worse than).
Tapes - pretty reliable - apart from zx81
CDs - hmmm - tbh a few of mine are a bit flakey after 10 yrs so I hate to think what theyd be like 3 times that.
Core Memory - I have some from a Wang calc from 1957 - are the last calculations are stored in this memory?
And yes, one of my first investigations into Hunter programming was the POWER ON RESUME
note to self - do not code infinite loops when you have to take 30 odd machine screws out to reset the internal CMOS
Like the Liberator - a great piece of design - the Liberator is almost futuristic (though if I showed you some of the internal fit of early non-CAD moulding you'd realise why most photos look like Morris Marina panel fittings on a Friday with the Rovers playing at home. The main pcb is about 2mm too long for the case for example, and the port holes are a good 5mm to one side.
Despite this - it absolutely brilliant. Some of the wikiped is wrong - its not an fpga, and its more like the Hunter on batteries - 40hrs++ with AAs
I like the Husky because of the boot Logo - uncannily like the Lynx Pawprint.
Please have a try of my emujlator - its quite useful for things non Lynx related.
br Peter
It the Lynx that you refer to the same one that had something to do with Nascom? I think that there was some sort of tie up at some time, along with Lucus, just as it all went **** up.
The CPLD will be a Xilinx XC9572 PLCC84, because I have some - and it all seems about the right "retro-ness". I have a few of Altera EPM7128's but all surface mount, they are OK for the final version, not for the half dozen trial ones! I do like the Altera software better but I can get by with ISE (on simple stuff like CPLDs). I harbour dreams of being intelligent enough to tackle some ancient FPGAs at some point as I have some old Cyclone ones to steam off.
As for the electric pulses ... I have to go for for a head MRI soon ... I am going to be EMC tested too!!
@ Dr_A
On CP/M what is the usual (if there is one) way to bank switch? Is there a normal amount to be switched? and from a normal address?
Alan
http://www.wisegeek.com/what-is-bank-switching.htm
http://en.wikipedia.org/wiki/Bank_switching
http://en.wikipedia.org/wiki/Sideways_address_space
I am putting together a CP/M board from old bits (as usual) and as there is a 128KB ROM (only 8KB needed at boot) and a 128KB RAM it seemed a bit of a waste not to use the other bits of memory. I have a CPLD for glue so the map could be changed, if and when I know what I am doing!
Just to make things a bit more of a challenge Grant Searle's site is down for the second day :-(
Alan
Best idea would be to check out the N8vem project by Andrew Lynch.
https://groups.google.com/forum/#!forum/n8vem
Schematic:
http://n8vem-sbc.pbworks.com/w/file/28766758/sbcv2%20SBC-schematic.pdf
In your case, with a larger than real life ROM, the same trick would be required for the ROM as well.
Or take a hit on the ROM size in return for simplicity?
Bank switching can mess with your head!
Perhaps the simplest is the N8VEM. Blocks of 32k that you can switch in and out. That works well for ram disks. However it may not be the most optimal for variants of CP/M. I don't think CP/M 2.2 uses bank switching, but if you go to MP/M, you need to put the operating system in high memory, try to get it as small as possible, and then grow the memory down from the top. So in practice, you start writing code and every now and then you run out of space and so add another 2k. I think I got MP/M into about 12k. Or you can put 16k at top for the operating system and 48k for the programs. Of course, once you start writing programs in C or Basic or Fortran or Pascal, you want as much room as possible for your code, so there is motivation to make 48k a bit bigger. Or (crazy idea), move the entire operating system into another bank and have 64k available for your program.
So you have to decide how big to make the banks - 32k, 16k, 2k or something else.
Smaller bank blocks are the most efficient in terms of least wastage of ram, but need more driver logic.
I've even pondered crazy ideas, like taking 512k of ram, chopping it up into 2k blocks and any block can be mapped to any location, and then use another (smaller) ram chip to do that mapping.
But CPLD is another great way to go, because glue logic for banked memory can become quite complex.
The idea I'd like to explore is what I am going to call 'propeller bank mapping' and it has very little hardware as each 64k block is independent. I don't think this was ever done in old computers, because how would you jump between the blocks without a common block of memory between banks? But with a propeller chip, the Z80 can pass data between blocks by sending some data to the propeller, then send a message to shut itself down, then the propeller can stop the clock, change the memory bank, do a reset, restart the Z80 and move the data back into the new block. All untested as yet, but I think it should work.
Dr_Acula
I'm not sure if you are aware, but you'd just described an amazing way to do some kind of totaly re-configurable, patchwork style memory mapping!
It can be simultaneously a bless and a mess to deal with, specially having in mind the way relative jumps across page boundaries would work in the such a Propeller/Z80 realm.
I suspect, just a shallow glimpse of my own thoughts, that some kind of prefix should be added to the existing Z80's address referencing instruction subset coding, to actually deal with such a scheme.
Even if we must recur to the old Define Byte or Word code insertion, it will be a total fun.
Oh boy, it can become an addicting way of big stuff coding, using Propellers and Z80s together!
Yanomani
He he. It sure can get confusing. I'll explain it a bit more - mainly so I understand it
Ok, simple bank switch as used in the N8VEM - 32k blocks and you have one latch and if A15 is low then it always addresses the lowest 32k, and if A15 is high then the latch selects the block (eg for 512k there would be 16 blocks of 32k so you need a latch with 4 bits). You could add a second latch, and map the lower 32k as well. But each time you add more bits (ie smaller blocks) , you need more latches and it gets impractical very quickly.
A second small ram chip solves the problem (in this case, 256 bytes of memory).
Consider 512k of ram with A0 to A18. A0 to A10 go into the ram chip from the Z80 and that is 2k. Z80 A11 to A18 go into the address lines (A0-A7) of a small ram chip, and then the D0-D7 of that ram chip go to A11-A18 of the 512k ram chip.
The small ram chip replaces lots of latches, and may well end up simpler than a CPLD as well.
2k blocks of memory, mixed up in any way you want them.
The challenge, and I haven't worked this out yet - how do you program that small ram chip with the least number of glue chips?
It may be CPLD can do this. So - CPLD vs some glue chips and a small ram chip.
Or, since this is a propeller forum, maybe the propeller chip has the job of programming that small ram chip? Old skool 6116 (but fast one, eg 15ns http://compare.ebay.com.au/like/121129736823?ltyp=AllFixedPriceItemTypes&cbt=y&_lwgsi=y&lpid=45&item_id=121129736823) and set the Z80 to HiZ under propeller control, then program in all the bank locations using a MCP23017, then set the MCP23017 pins all HiZ and restart the Z80.
" I don't think this was ever done in old computers, because how would you jump between the blocks without a common block of memory between banks?"
This is the scheme used by the Lynx - full 64k bank switching - as far as I'm aware its unique for a home comp. You just have to make sure that the code context carries on across the switch by duplicating code in others banks. It can get complicated
Although the whole 64k gets switched the ROM in Bank 0 is given priority on reads below the 24k boundary (and above E000 where the ROM for the Disk OS sits) in situations where multiple banks are selected for reading thus giving the 'common ground' you mention. So in general you would copy some ROM code off to another bank, then switch out the ROM and move the context into the new bank.
As an example, to print a character from CPM (in Bank 1) the PC moves into the E000 area (which is a duplicate of the ROM) and then the RAM is switched out and ROM switched in - context is now in Bank 0. The graphics output is in the Lower 100h bytes of ROM which is duplicated across to Bank 2 (Video RAM). Context is then switched across into the Video bank RAM and writing the screen occurs. Then the reverse sequence of switching occurs again to get back to Bank 1 and continue CPM.
So even for CPM 2.2 on the Lynx theres a lot of bank switching going on. The attached shows the Banks 0 1 2 layout for CPM running on the Lynx.
It is my ancient past where a 2K x 8 SRAM was " Ooooh.... shiney!" and half a dozen people stood motionless, pointing. So to kiss goodby to 64K SRAM and 96K EPROM seems a crime. I will have to get it working on CP/M 2.2 first then try for 3+ :-)
There will be a Prop for it,as a Terminal
Brilliant! This sounds like something we could replicate for the propeller. It should be easy to duplicate the code - that could be done at startup with a small library of common code in the same location in each 64k.
How did the Lynx transfer data between 64k banks?
The bank latch (pictured on the RHS) is a simple set of bits for R/W control, you can select multiple banks for read or write (its programmers responsibillity to avoid bus contention). So a transfer fro m one bank to another is setting up the Read/Write bits on the latch and then copying using ldir.
as I write its 2013 and I'm sitting here soldering up a CPLD to an ISA passive backplane - great days
a CPU upgrade for my project with a Prop running four or five processors - z80, 6309, 68008, 6502 and V30 - each able to
access the Lynx main memory on a basis similar to the Prop hub.
Todays Sram upgrade along with a couple of rejiggings to eh decode has jumped the Lynx from 128 to 768k - its very extendable.
At present I'm going ahead with my Lynx - CPLD - ISA - VGA idea at the moment. I've looked around at some dsPic - VGA things but they're too much 'on the edge' and not enough res/colours. The closest I can see is baggers Spectrum emu running on the dracblade(?) - is the whole of the speccy memory (inc vidram) external?
I'm not sure the muxed adressing schemes would scale when I shift the z80 speed up to 20mhz? If anything I'd probably use the one prop just for VGA output and as many pins as poss for the memory access.
That sounds a pretty cool upgrade!
VGA on the Propeller looks great when you first see it - a little chip doing text and graphics, but the 32k hub ram does have limitations with graphics. A VGA card with an ISA bus sounds intriguing. I looked up the ISA bus specs and it looks like something to explore further. Reaching back into my memory banks of the past, were early VGA cards about 1mb of memory? If so, you do get a lot more options than with 32k of memory.
house is still being pulled apart - new bathrooom going in now!
Here's what I've hooked up to play with - phew quite a bit of wirewrap.
http://www.camputerslynx.info/PALE/ProtoBlog6.htm
I'll get together a list of the connections I made, see if anyone can spot some gotchas.
peter
Oh btw Dr_A - I think the Morpheus drivers may be able to do what I want (for the simple Lynx output case) - do you know if theres a list of what drivers are available for the board? I'm looking for 256x256x8 and 512x256x8.
CPLD Pin Lynx Exp. Port Pin
4 1 D0
5 2 D1
6 3 D2
8 4 D3
9 5 D4
10 6 D5
11 7 D6
12 8 D7
15 9 A0/A7
16 10 A1/A8
17 11 A2/A9
18 12 A3/A10
20 13 A4/A11
21 14 A5/A12
22 15 A6/A14
24 16 A13/A15
25 29 /MREQ
27 30 /WR
28 31 /IOREQ
29 33 /RD
30 39 WREN2 *modified
31 40 RDEN2 *modified
60 22 /NMI
81 26 /WAIT
CPLD Pin ISA BUS Pin
33 A0
34 A1
35 A2
36 A3
37 A4
39 A5
40 A6
41 A7
44 A8
45 A9
46 A10
57 /MEMW
58 /MEMR
67 /IOR
68 /IOW
69 D0
70 D1
73 D2
74 D3
75 D4
76 D5
77 D6
79 D7
80 ALE
CPLD Pin ISA 16 BUS Pin
48 D15
49 D14
50 D13
51 D12
52 D11
54 D10
55 D9
56 D8
61 /REFRESH
63 A19
64 SBHE
65 '373 Latch CLK
(A11 - A18 are multiplexed from D8 - D15 using a '373)
and a few clock lines.
Grant Searle recently showed us how to build a CP/M computer with this site http://searle.hostei.com/grant/Multicomp/index.html
But what he didn't do is give you the working code. He makes you put it together step by step, and in doing so, teaches the basics of VHDL.
The final product is an emulation running about 10x faster than the best propeller emulation, for about the same cost. There may be scope here for a propeller/fpga hybrid. Though the way fpga chips are falling in price, there may also be scope for a propeller emulation within the fpga. Today's cutting edge chip seems to be tomorrow's retro emulation.
I feel a fpga/propeller hybrid coming on. There are a few things that the propeller may do better - audio, and handling multiple complex tasks in parallel. I wonder how minimalist a propeller circuit could be? Replace the xtal with a clock from the fpga board? Replace the eeprom with an emulation of an F10 download?
Yes, hookup power and bypass, provide a clock from FPGA pin, hook another FPGA pin to reset, either simulate a load across P30 & 31 of have your FPGA look like an EEPROM on P28&29. All doable from Prop to Prop, should be doable from FPGA to Prop.