Shop OBEX P1 Docs P2 Docs Learn Events
TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC) - Page 27 — Parallax Forums

TriBlade Prop PCB: Uses 3 Propeller ICs for a Single Board Computer (SBC)

1242527293032

Comments

  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-14 01:14
    @heater - making lots of progress. Have put many messages through the spin code and single stepping it through. Runs ziboot then stepping through this code and got to
      FF4E    DB FD                     in    a,(hdskport)        ; perform operation and get result
      FF50    B7                        or    a
      FF51    CA FF55                   jp    z,cont1            ; continue if no error
      FF54    76                        halt                ; halt otherwise
      FF55    79                    cont1:    ld    a,c            ; save loop counter in <A>
    
    



    The in a(hdskport) gets trapped by the spin code and reads a sector off the sd card and writes it to memory location $0000 This appears to be:
    000 C3
    0001 00
    0002 01
    0003 E5
    0004 E5
    and then E5 for all the rest
    
    



    Which I think is a jmp $0100

    But then it seems to fall apart at FF50 with the "or a"

    Single stepping gives this:
    ...
    007E E5
    007F E5
    Write finished
    128 bytes written to memory
    PC=FF50  AF=0044 BC=0058 DE=0008 HL=0000 IX=0000 IY=0000 SP=0000
    Spacebar for next instruction
    PC=FF51  AF=0044 BC=0058 DE=0008 HL=0000 IX=0000 IY=0000 SP=FFFE
    Spacebar for next instruction
    PC=FF52  AF=0044 BC=0058 DE=0008 HL=0000 IX=0000 IY=0000 SP=FFFC
    Spacebar for next instruction
    
    



    The SP is decrementing and it neither does a halt nor a jump.

    What does the "or a" do, and can one guess from the F register of 44 whether Z is set or not?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 11/14/2009 1:21:46 AM GMT
  • heaterheater Posts: 3,370
    edited 2009-11-14 05:51
    Off the top of my head:

    1) Prior to the "in a,(hdskport) " there is a bunch of OUT instructions to the hdskport setting up a read command with disk, sector, track and DMA address parameters.

    2) The " in a,(hdskport) " then triggers the actual disk read command. So at this point emulation should pause while the disk sector is DMAed to the buffer at DMA address and then a success/fail result returned in the A register.

    3) A return value of zero in the A register means "success" but the IN instruction does not set the Z flag. So "or a" is used to set the Z flag from the content of the A reg. One might think to use a compare with zero here "cp 0" but that is two bytes instead of one. Programmers used to think about such things.

    4) It seems in your case the disk read has returned with A = 0 which and F = 44H after the OR instruction which is indicating ZERO (in bit 6) and PARITY (in bit 2).

    5) At PC=FF51 things are going bad because the jump is not taken when it should be and we end up at PC=FF52 which really should not happen as it is in the middle of a three byte instruction.

    Why this is going wrong I can't say. I'll try to think about it.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-14 06:57
    Thanks heater. That gives me quite a few things to experiment with.

    When it does an 'in' from the hard drive, does that pause execution of the zicog in some way until the spin code has transferred all the bytes over? How does that part work?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
  • heaterheater Posts: 3,370
    edited 2009-11-14 10:42
    If you look at the I/O emulation in zicog.spin you will see that having set up the I/O port number and the I/O command they both do this:

    :wait                   rdbyte  data_8, io_command wz
                  if_nz     jmp     #:wait
    
    



    So the PASM execution hangs in these loops until the output byte is handled or the input byte is available. That is until the hardware emulation in zicog_cpm.spin sets the io_command back to zero.

    So in zicog_cpm.spin you will find "io_command := 0" at the end of the on_input and on_output methods.

    In this way either the PASM emulation is executing or the Spin hardware emulation is executing. Never both at the same time.

    So yes for hard disk reads the block transfer is triggered by IN from the hdskport which will hang up the PASM until the Spin has fetched the required block and written it to the DMA buffer. At which point io_command is set back to zero causing the IN emulation to exit the wait loop.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-14 12:48
    Ok, that is cunning.

    Am still working through some code - I've got two bugs to squish - one is that the first record off drive 0 does not seem to be correct. And second it still having trouble with the low level ram access.

    Can I ask - in which file does CP/M reside on the sd card and which bit of code loads this?

    Stuck at the moment - memory getting corrupted. Narrowed it down in a single step routine to the PRI on_break - if add just one memory read to a random location after the printout of the registers, the whole zicog falls over. Ditto a write, but the fact it does it just after a read is kind of suggesting there is a clash somewhere and the zicog is still trying to access the memory too. No problems with all sorts of memory read/writes before the zicog cog is started.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 11/14/2009 2:05:47 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-11-14 17:24
    How about HDCPM2_A.DSK, aka ZIPM2.DSK, the 8MB CP/M 2 boot disk. Assuming you are not wanting to boot from a floppy image.

    Not sure I understand "which bit of code loads this?". CP/M is on the boot sectors of that disk and is loaded by the boot loader ZIBOOT.COM that you have been stepping through.

    ZIBOOT loads the boot sectors to 0000H in RAM and jumps to 0. From there should be a jump to 100H, if I remember correctly, where the is a little code to move the CP/M stuff to the right places in high memory. Look at MOVER.MAC in altairz80.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-11-15 00:46
    Drac: Wow - I didn't bother to understand heater's code - it just worked so I only did the interfacing part.

    Welcome to Jack - he has just received his TriBlade and wants to get CPM running tongue.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 11:30
    Talking about understanding code ...

    Heater Have I too simplistic thinking about how the 64KB ram load happens and is the invoked. I think you load the whole of the 64K above page zero with nops until the rom bits are run into, and kick in. I want to load 4KB, to start with, and the probably all 64K as a system image (Nascom)

    It would kick off at 0000. I will have to translate the I/O stuff to talk serial and put the "Nascom" into X-xx mode (prob X20) tor terminal mode

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • heaterheater Posts: 3,370
    edited 2009-11-15 11:57
    I think you understand it just fine.

    Thing is a Z80 starts execution at 0000 after reset but computers like to have RAM at 0000 and any PROM in high memory. In CP/M for example.

    So in real hardware there used to be some memory switching that would have ROM at 0000 on start up but then switch it to RAM after that.

    In ZiCog we don't bother, just fill RAM with Zero (NOP) and let it run up to the ROM at FF00.

    So just put what ever you want in RAM and run it.

    Did a NASCOM use such hardware RAM/ROM switching ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 12:13
    Heater

    0000-07FF 2K monitor rom
    0800-0BFF Video ram (character mapped)
    0C00-0FFF Ram (some used by monitor, some used by SP, some left for the user!! )

    I/O port 0 for KBD
    1 and 2 for UART data/status

    This made up the bare minimum for the N1 everything else was extra. Not bad for a month's salary.

    So yes there is rom at 0000 to kick strait into monitor, N2s did put a restart vector on so that at 4KB boundries restarts could be altered, but the rom addr stayed put at 0000. I can't remember if the later Nas-Sys monitors were written relocatable or not, it was the Holy Grail of coding back then.

    I suppose I could be perverse and try to write a CP/M program that emulates a Nascom, to run on an emulator ....

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • heaterheater Posts: 3,370
    edited 2009-11-15 12:22
    Sounds good Toby.

    Be aware that ZiCog is still missing a number of Z80 ops. EX, EXX, anything to do with block comparisons and such. No idea if NASCOM used these. Do you have any monitor listings to look at and check for these. In theory ZiCog will stop and dump registers if it finds an op it does not recognize so you will find out eventually.

    Problem is we have precious little COG space left in which to implement any more ops even after our heavy use of overlays.

    "I suppose I could be perverse and try to write a CP/M program that emulates a Nascom, to run on an emulator ...."

    No don't do that, we are all quite perverse enough already wanting to run Z80 codes in 2009 [noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-15 12:24
    Success! The single prop zicog with keyboard and vga is now running:
    SD started
    SD mounted
    A:ZIPM2_6b.DSK 852817 515595148
    B:ZICOG_A2.DSK 639825 515595148
    C:DRAC2_64.DSK 279185 515595148
    D:ZICOG_SC.DSK 803665 515595148
    E:ZICOG_E2.DSK 721745 515595148
    F:ZICOG_F0.DSK 738129 515595148
    G:ZICOG_G0.DSK 770897 515595148
    H:ZICOG_H0.DSK 787281 515595148
    R:BOOTHDSK.32M <-bootcode 115281 515595148
    Loading SRAM...
    Skip filling memory with zero
    Ram test, should print out C3 00 FF = first 3 ram bytes: C3 00 FF
    Read boot code from SD card and store at $FF00
    Boot code loaded
    Starting 8080 emulation...
    Passed, please wait...
    
    64K CP/M Version 2.2 (ZiCog, BIOS V1.27_Zi04, 8 HD, 10-Sep-2009)
    
    A>b:
    B>mbasic
    BASIC-80 Rev. 5.21
    [noparse][[/noparse]CP/M Version]
    Copyright 1977-1981 (C) by Microsoft
    Created: 28-Jul-81
    32824 Bytes free
    Ok
    10 for a=1 to 1000:next
    20 print "done"
    run
    done
    Ok
    
    



    The BIG unknown with all this is how fast it would run with the need to latch address bytes in seperately to the ram. I've done a speed test and compared with a real N8VEM I'm guessing this emulates at about 2.5Mhz. An acceptable speed compromise IMHO. Especially when off-board compilation and development can be done using the N8VEM tools that shell out to the SIMH.

    The part that is much slower is the disk block transfers. In order to get the debugging working I took cluso's ramblade driver and rewrote it for this board and did it all in Spin. Much easier to trace through the execution when the spin code is in the Main object. But now that this works, and now I also have a zicog pasm driver I can copy that code into a new driver in a similar way to cluso's driver.

    And the bit that has had me stumped for the last week? Well, I still don't know exactly but I think it is due to two things trying to access a pin at the same time. I think fsrw alters the pins in between the lowest and highest pin numbers. So the secret was to tristate all pins after every memory read and write - both in spin and pasm. This way, if the fsrw wants to do its thing at the very least the gate on the 138 will be tristate (pulled high with 10k) and so the ram is protected. Maybe it wasn't fsrw though, because without the tristate in pasm at the end of a read, the memory got wiped before it even got to the stage of single stepping the first instruction.

    Next challenge - trying to recover about 13 bytes out of the zicog in order to get Z80 opcodes working.

    All good fun! And a big thanks to Cluso and Heater for all their help over the last few weeks.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build

    Post Edited (Dr_Acula) : 11/15/2009 12:34:51 PM GMT
    1280 x 960 - 317K
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 12:30
    Smart**** !

    I suppose the next version will be one prop less !

    Heater

    I don't recall any useage of EX ... etc Block transfers gallore but not compares ( but it was 30 years ago )

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point

    Post Edited (Toby Seckshund) : 11/15/2009 12:37:17 PM GMT
  • heaterheater Posts: 3,370
    edited 2009-11-15 13:19
    Dr_A. Wow, that is truly fantastic. Looking forward to seeing a screen shot of Wordstar running on a single Prop computer.

    Looking at your board I wonder how you managed to route from Prop to RAM all the way across the board. I would have been tempted to put all the chips on one side and all power supply, SD card and I/O on the other. Still if it works it works.

    Not sure where we are going to get the extra space from in the COG. As you may have noticed I've been playing with the idea of splitting code over multiple COGs again for the 6809 emulator instead of using overlays. Not sure I've got the heart or tenacity to rewrite ZiCog yet again though.

    How many COGs will your board end up using ? Perhaps we could move the biggest overlays out to another COG thus shrinking the required overlay area size. That would be DAA for starters. Makes for a rather messy implementation though.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 13:40
    Dr_A

    Will that design be coming out to play, or is a comertial venture ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 14:33
    Heater

    Just looked thru the hex of Nas-Sys3 and it does have EX AF,AF' dotted all over it. Could be a cue to learn how you added bits in. ( or get my finger out and get a real Z80 going )

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • SapiehaSapieha Posts: 2,964
    edited 2009-11-15 15:09
    Hi Toby Seckshund.

    If It is only instruction them use "EX AF,AF'" ..... It is only rapid substitution of --- Push, Pop AF to and from Stack
    And You can reedit code ... Most posible You ned have one RAM Variable to spare AF as it can span over more that one RETURN from stack

    Like.
    Push A
    MOV A,AF
    MOV MemVar,A
    Pop A

    As You see that saved in Z80 many opcodes and External MEM operations

    Regards
    ChJ

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer.
    Don't guess - ask instead.
    If you don't ask you won't know.
    If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


    Sapieha
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 15:42
    Sapieha

    Yes i could do that but some of them are closly packed into the restarts locations so I would have to vector out into clear space recode and then dive back in. I am still thinking about getting brave and mimicing/adding to the overlay tricks. All part of the education.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • SapiehaSapieha Posts: 2,964
    edited 2009-11-15 15:52
    Hi Toby Seckshund.

    If them are used in RESTART/INT Vector place's ....Them are direct Replacements for ..... PUSH and POP AF on stack with no ned for Spare them as Variables to later use.

    Regards.
    ChJ

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Nothing is impossible, there are only different degrees of difficulty.
    For every stupid question there is at least one intelligent answer.
    Don't guess - ask instead.
    If you don't ask you won't know.
    If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


    Sapieha
  • heaterheater Posts: 3,370
    edited 2009-11-15 15:57
    What are you running this on Toby?. On Triblade there were only 6 LONGs left! As a small system on a demo board with Z80 RAM in HUB there was a tiny bit more.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 16:21
    Heater

    DemoBoard to start with then TriBlade if it ever gets to run. To make things even more doubtful I have just spotted a EX SP,(HL) and that is even used in the original Nasbug T2 monitor. It will be a lot easier to settle with your CP/M, and there is a whole bunch more of progs available.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • heaterheater Posts: 3,370
    edited 2009-11-15 16:30
    Ah but EX SP,(HL) is actually an original 8080 op where it was known as XTHL and we have got that covered.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Mike HuseltonMike Huselton Posts: 746
    edited 2009-11-15 16:33
    I stand in awe of your Mad Science. Push the limits!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    JMH
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-15 18:12
    Thats lucky then. I got all disappointed and had a route about in the garage. From long ago I have the front control board from a Panasonic DVC 640 machine. It has got a Z180, 32K EPROM, 32K RAM and a 8255 type. Perhaps I won't have to use it after all.

    The telling thing is ... This old panel has got far more grunt to it than the Nascom ever did, and it's place in life was to just wait for a button push.

    I was also thinking that with a rewrite of the monitor There should be room for the Triblade Nascom as the VDU memory will not be used so the monitor could creep up, but would have to be write protected. It would stop any games, which might not be a bad thing, BUT ... I may as well use the CP/M progs which you have already sussed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • JackRubinJackRubin Posts: 4
    edited 2009-11-15 22:09
    Greetings to all -

    As Ray noted a few msgs back, I just got my triblade and look forward to getting it assembled and running CP/M. Glad to see some familiar handles here as well. James, do you ever sleep?

    I started computing in the early '70s, running RT-11 on a PDP/11 as a grad student and shortly thereafter moved to CP/M 2.2 on a Cromemco Z2. Gave up my thesis work for blinking lights and never looked back. Today, I'm IS Director for a small private college in Chicago and still messing around with 8-bit machines to relax after days spent running virtual W2K8. Lots of S100 stuff kicking around the basement/garage/attic and a growing pile of 6502 (Apple/Atari)·boxes as well. Moving slightly upstream, DEC PDP/8's still have a strong hold on me too, with some real iron and a couple emulators.

    It's been way too many years since I even hacked a BIOS or modified MODEM7 for new hardware, to say nothing of doing serious coding, so I will mostly be watching slack-jawed as you guys continue to grow·this project from bare metal.

    Jack

    Chicago, IL
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2009-11-15 22:40
    @jackrubin - re sleep, I am doctor acula *grin*, I prefer to work all night...

    @ Toby Dr_A "Will that design be coming out to play, or is a comertial venture ?", It is all open source. There is the schematic posted on this thread a week or two ago, though it has changed slightly as it evolved. And it may change again - eg I built it for vga, but I got a 4" TV screen the other day so I'd like to try TV as well. Cluso (very wisely!) put both options on the triblade. I've got another board being made that has all the mods on it and I'll probably have a few spare.

    Still some code changes to make. Ideally I'd like to have a drop in object that does the driving for this particular board and then a single ifdef at the beginning of the code that selects the triblade or the dracblade. Then all the software options can move forward as one single piece of code.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/build
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-11-15 23:43
    Drac: Congratulations smile.gif

    Jack: Welcome to the madhouse !!

    Toby: A friend of mine in New Zealand has re-bought a few Nascoms and he has a prop proto which I helped him interface to a Motorola D2 - replaces the keyboard and 7 seg display board with a prop with either keyboard + VGA or PC.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • heaterheater Posts: 3,370
    edited 2009-11-16 00:00
    Dr_A: "dracblade" does sound particularly menacing [noparse]:)[/noparse]

    Jack: Welcome, this is not a mad house, we are just psychedelic relics. Good luck with the TriBlade.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Cluso99Cluso99 Posts: 18,066
    edited 2009-11-16 10:10
    heater: I was just looking at the ZiCog code and there are a few places that some instructions could be shaved.

    'Increment pc before fetching next instruction
    inc_pc2_fetch  add pc, #1                '<-- takes an extra instruction but saves a long
    inc_pc1_fetch  add pc, #1                '<-- saves a long
     
    'Instruction fetch loop starts here
    disable_interrupts
    enable_interrupts
    fetch
    
    

    There are a few other places that could·save a jump by reorganising code.

    Need to get back to a Release version 1.0 first !

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Links to other interesting threads:

    · Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
    · Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
    · Prop Tools under Development or Completed (Index)
    · Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
    · Search the Propeller forums·(uses advanced Google search)
    My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2009-11-16 15:39
    Clusso

    The last time I saw a Nascom2 for sale, was about a year ago. It was in Holland and cost 300 euros +++. I then realized that all the old stuff I didn't have anymore would be worth a fortune.

    Where is that cat ?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
Sign In or Register to comment.