MP3s and Ethernet - CP/M

This is a discussion on MP3s and Ethernet - CP/M ; Is anyone here interested in the idea of a S-100 card with an ethernet chipset and mp3 decoder? I thought it would be fun. It would be easier if some developers out there had too much spare time and money....

+ Reply to Thread
Results 1 to 18 of 18

Thread: MP3s and Ethernet

  1. MP3s and Ethernet

    Is anyone here interested in the idea of a S-100 card with an ethernet
    chipset and mp3 decoder?

    I thought it would be fun. It would be easier if some developers out
    there had too much spare time and money.


  2. Re: MP3s and Ethernet

    "logjam" wrote:

    > (...) It would be easier if some developers out
    > there had too much spare time and money.


    Grant, in case you have not yet understood after all this time, if you don't
    do something by yourself, alone, nobody else will do it. (In addition, if you
    do something, some people will critic you...)

    So, instead of asking lots of things that you would like other people to do,
    you'd better think hard for a few hours, then decide what would be really
    needed, then find the will/time/money to do it.

    Myself, I have dozens of interesting programming projects for CP/M. The big
    problem is that I don't have enough time and/or money to do them. When I
    manage to finish something, I take the time to write a "mini article"
    explaining the why of the how. See HEXBIN, recently published, for an example.

    Yours Sincerely,
    "French Luser"




  3. Re: MP3s and Ethernet

    On 24 Aug 2006 00:53:55 -0700, "logjam" wrote:

    >Is anyone here interested in the idea of a S-100 card with an ethernet
    >chipset and mp3 decoder?


    There are a few technical issues to over come.

    Mp3... what data rate? S100 with Z80s can sustain a burst of data
    shorter than 64kb at around 180 kbytes/S. Some of the 8088 boards
    can do a bit better. DMA is the solution. However if CPU
    intervention is required your likely cpu is z80 or 8088.

    NOTE on CPUs, S100 is generally a 8080/z80 world. Though over the
    years 8088, 68000, and even near the end up to 386s were on S100
    though those are rare.

    Side problem is S100 only (696 standard) goes to 24 bits address
    (16mb) I've seen only one system with one megabyte of ram in it
    and I built that system.

    Bus (s100/696) data rate can hit as fast as 8mb/S but few push it that
    far (usually a fraction of that) and it will have to be a decent
    backplane with termination to support that.

    Now Eithernet is doable and there were S100 eithercards (not arcnet)
    but most of the software for them was for 8088 and higher 16bitters.
    IP stacks for Z80 (the most common s100 is Z80) have been done
    (UIP and others). There are problems at eithernet speeds processing
    sequential packets fast enough and providing enough buffer space.

    >I thought it would be fun. It would be easier if some developers out
    >there had too much spare time and money.


    developers with time and money are rare. Usually they have either!


    Allison

  4. Re: MP3s and Ethernet

    On Thu, 24 Aug 2006 10:48:01 +0200, "French Luser"
    wrote:

    >"logjam" wrote:
    >
    >> (...) It would be easier if some developers out
    >> there had too much spare time and money.

    >
    >Grant, in case you have not yet understood after all this time, if you don't
    >do something by yourself, alone, nobody else will do it. (In addition, if you
    >do something, some people will critic you...)


    Some people that have no concept of what kind of processing is
    required to do MP3 or Eitherneta(at eithernet speeds) will encourage
    you.

    In the age of super fast cpus and huge memories in the sub 10ns range
    it's easy to forget what it takes to decompress MP3 or assemble
    eithenet packets even at the lowly 10mb/S rate.

    >So, instead of asking lots of things that you would like other people to do,
    >you'd better think hard for a few hours, then decide what would be really
    >needed, then find the will/time/money to do it.


    First is do the needed study to understand feasability. While it's
    easy to assemble a MP3 with Ethernet using moden PC componenets
    both hardware and software none of them exist for S100.

    The average S100 system has only floppy.
    The exceptional S100 system has a slow hard disk (less than 30mb).
    The average S100 crate runs CP/M or similar (single task os).
    PCdos was ported to S100 with 8088/8086 cpus.
    The average s100 system is 4mhz z80.
    The expectional S100 system has afaster z80, 8088 or maybe 68000
    (faster being 8-12)mhz).
    The average s100 system is 64KILOBYTES of ram (or less).
    The largest commonly found card is 256k, 1mb cards were made.
    The average S100 IO is 9600baud (or slower) serial
    There were systems with arcnet and Etherenet
    (and 8088 or 286 cpus).
    The average S100 system has a parallel printer port (basic
    unidriectional).
    There is a single board available for S100 that brigs IDE to the bus.
    IDE designs for S100 are slow (byte/word reconstruction).

    What resources are there to do MP3 (data rates) or Ethernet
    packet buffers for adaquate data rates?


    Allison

  5. CP/M harddrive emulation on a PC connected with a real CP/M computer

    French Luser schrieb:
    > "logjam" wrote:
    >
    >> (...) It would be easier if some developers out
    >> there had too much spare time and money.

    >
    > Grant, in case you have not yet understood after all this time, if you don't
    > do something by yourself, alone, nobody else will do it. (In addition, if you
    > do something, some people will critic you...)
    >
    > So, instead of asking lots of things that you would like other people to do,
    > you'd better think hard for a few hours, then decide what would be really
    > needed, then find the will/time/money to do it.
    >
    > Myself, I have dozens of interesting programming projects for CP/M. The big
    > problem is that I don't have enough time and/or money to do them. When I
    > manage to finish something, I take the time to write a "mini article"
    > explaining the why of the how. See HEXBIN, recently published, for an example.
    >
    > Yours Sincerely,
    > "French Luser"
    >
    >
    >


    I agree with you. There are much more ideas than
    developers/implementors. So, thinking in small steps would be much
    wiser. But may be some have already done a similar project (I do not
    think so, because the Z80 and the S100-Bus would not support high
    bitrates IMHO may be not much more than 64KBit MP3 bitrates), so just
    the question is not a bad thing.

    To be honest: I've some considerations already done about a cheap
    network solution, but not full-featured, instead, just to connect a mass
    storage via a network-alike connection. My idea was to change an already
    existing RAMDISK source for CP/M to a virtual drive solution via the
    parallel port.
    On the other side should be a (even old) PC, which emulates a CP/M
    harddisk (means, this PC side will offer a 8 or 512 MB HD in a low level
    sector manner, which would be a container file on a PC harddisk.
    This project should be easily implemented for me in the next time, but
    my first problem is not the knowledge, instead the missing time :-(

    Regards
    Peter

    My new project: Try http://www.z80.eu for CP/M computer infos.

  6. Re: CP/M harddrive emulation on a PC connected with a real CP/M computer (was: "Re: MP3s and Ethernet")

    On Thu, 24 Aug 2006 15:20:09 +0200, "Peter Dassow (remove the NOSPAM.
    for direct answer)" wrote:

    >To be honest: I've some considerations already done about a cheap
    >network solution, but not full-featured, instead, just to connect a mass
    >storage via a network-alike connection. My idea was to change an already
    >existing RAMDISK source for CP/M to a virtual drive solution via the
    >parallel port.


    This has been done via serial port. There is at least one
    commercial one Filink (for epsom PX8) that used a CP/M system as a
    host.

    I started doing this back in '81 so some of my non-disk equipped
    sytems could use another cpm system as a host via serial line. The
    code was system specific to my hardware but in general form it's
    Client BIOS to serial and serial to BIOS on Host. If you ever worked
    with a CP/M BIOS you know thats where CP/M expects all it's logical
    requests to be translated to hardware action (abstraction layer).
    So a BIOS can literally interface to anything that can simulate a
    block addressable storage. Adding a serial line or parallel line
    in the middle of that is strictly a transport issue.

    >On the other side should be a (even old) PC, which emulates a CP/M
    >harddisk (means, this PC side will offer a 8 or 512 MB HD in a low level
    >sector manner, which would be a container file on a PC harddisk.
    >This project should be easily implemented for me in the next time, but
    >my first problem is not the knowledge, instead the missing time :-(


    FYI: CP/M (Not any of the enhanced versions like CP/M3 or Zrdos)
    is limited to 8mb logical disks (65535x128 byte sectors) and 16 disks
    maximum. The Improved versions can address up to 2GB but with a flat
    file system and fixed directory size anything over 32mb would not be
    as useful as smaller partitions. There are some system management
    issues there.

    Disk emulation via PC is straightforward (use dos or linux for less
    pain). All you need is a fixed size file file whose content is a cpm
    file structure and a way to communicate with the CP/M system. That
    means a CBIOS that knows the transport (serial, parallel or Vodoo)
    media it's protocal (can be homebrewed) and can effectively transmit
    requests for DRIVE, TRACK, SECTOR (and 128 bytes of data
    for a write) to the host and the host needs to translate that to
    reading and writing within the "container file" and transmiting the
    results back (which may only be status for a write). The container
    file for all intents is a database with the content being "directory"
    or "data". The details of CP/M file system and it's ODS is
    documented so there no secret and how the CP/M systems bios
    works is documented.


    Allison



  7. Re: MP3s and Ethernet

    I think you guys misuderstood me. I have already designed the ethernet
    card and MP3 decoder card. I'm making a Super-Altair card with 56k
    SRAM, 32k EEPROM, and 512k of flash.

    There was room left over so I put in support for the Packet Whacker
    from edtp and then added an MP3 decoder chip.

    I also have a video terminal on the board that supports NTSC/PAL and a
    PS/2 keyboard Right now it just emulates an ADM-3, but I plan to add
    VT100.

    Also included on the board is emulation for the altair disk drive and
    support for 8MB disks via MMC/SD cards.

    The ethernet decoder is an STA013. I wanted to use the MAS3507D
    because I have a lot of those things laying around, but they don't
    appear to be in production any more. I built an interface for the S100
    bus that has a 32k SRAM buffer. This provides up to 2 seconds of
    buffer time for a 128kbit MP3. A "regular" 128kbit MP3 only requires
    16kbyte/sec.

    Of course the altair can't actually decode the MP3 itself, I'm not
    crazy...

    I will post full specs in a second...


  8. Re: MP3s and Ethernet

    > What resources are there to do MP3 (data rates) or Ethernet
    > packet buffers for adaquate data rates?


    The ethernet chip on the Packet Whacker has a 16k buffer. This is a
    lot more than the CS8900 cards that I'm familiar with. I've never used
    the Packet Whacker yet, but I have hooked a CS8900 to an AVR. It is
    about 8 times faster than the Altair 8800, but was still pretty good.

    MAC address filtering will eliminate the need to actually transfer the
    packets from the ethernet chip to the S-100's memory.

    I imagined that it would be neat to run Contiki...

    The specs on the card are:

    LEDs:
    -Read Access (to any feature of the board)
    -Write Access ...
    -0-1023 RAM Access
    -RAM chip 1 Access (0-32k OR 1-32k)
    -RAM chip 2 Access (32k to the end of RAM space 56k or 64k)
    -EEPROM Access
    -FLASH Access
    -Ethernet Access
    -MP3 Access
    -2SIO Access
    -DISK Access (MMC/SD Flash)


    POJ: (Power-On-Jump)
    -A special SPLD device senses a reset. It disables the S-100 memory
    cards and provides a jump instruction to the address specified by DIP
    switches. For example, the altair could automatically jump to FF00
    when the reset switch is pushed. This feature will allow the ROM
    Monitor to come up without trying too hard.


    POR: (Power On Reset)
    -A function of the I/O processor is to reset the Altair on power up.
    Combined with POJ the Altair can automatically boot basic, monitor, etc
    with just a flip of the power switch - like an Apple II


    RAM:
    -64k of SRAM from two 62256 28pin DIP 32k chips
    -configureable as all 64k, or 56k (for ROM)
    -option to disable the first 1k so that the origional 88-1MCS MITS card
    can be used
    -option to disable the first 32k (for other RAM cards)
    -option to disable the second 32k ...


    ROM:
    -32k of EEPROM (programmable via the toggle switches if you wish)
    -512k of FLASH (only programmable via a program, unless you can toggle
    at a 6us rate)
    -option to select the "primary" ROM
    -option to completely disable the ROM
    -the primary ROM's 0-4k space is ALL WAYS 56-60k in the address space
    -a page select register selects a bank of rom from either EEPROM or
    FLASH for the 60-64k address space (this allows a boot loader to have
    MANY different memory images in the 512k space without taking up too
    much room)


    Ethernet:
    -10Base-T with 16k buffer space
    -option to disable the ethernet's I/O Address Space


    2SIO:
    -Both ports are emulated
    -1st and 2nd port can be connected to an External serial device
    -1st port can be connected to an onboard processor which provides a
    40x24 character NTSC/PAL video output and has a connection for a PS2
    keyboard
    -option to disable the 2SIO I/O address space (so a real 2SIO can be
    used)


    DISK:
    -Final details on numker of disks supported is not available.
    Inspiration from Altair32 Emulator
    -Raw access to MMC/SD card available to support large CPM partitions


    MP3:
    -Chip is used to produce the terminal "Bell" sound, as well as emulated
    disk sounds
    -Can be used to play MP3s off of MMC card or make the Altair a
    networked MP3 player via the ethernet interface.


    Thats it. Trust me, there is NO space left on the board!!! How does
    this sound?


  9. Re: MP3s and Ethernet

    On 24 Aug 2006 10:26:50 -0700, "logjam" wrote:

    >I think you guys misuderstood me.


    >Is anyone here interested in the idea of a S-100 card with an ethernet
    >chipset and mp3 decoder?
    >
    >I thought it would be fun. It would be easier if some developers out
    >there had too much spare time and money.


    What part of all that said you already did it? Sounded more like
    "hey anyone doing this?".


    > I have already designed the ethernet
    >card and MP3 decoder card. I'm making a Super-Altair card with 56k
    >SRAM, 32k EEPROM, and 512k of flash.
    >
    >There was room left over so I put in support for the Packet Whacker
    >from edtp and then added an MP3 decoder chip.


    sorta what I expected, PC tech on an S100 card, but what functions are
    the things on the s100 side doing for you?


    >I also have a video terminal on the board that supports NTSC/PAL and a
    >PS/2 keyboard Right now it just emulates an ADM-3, but I plan to add
    >VT100.


    Suggestion do VT52, vt100 is far more complex and few implmentations
    are even close to right. (VT100 does 132 char and 40char doublewidth
    and height (12 lines)). What usually ends up being build is 80x25
    with base ANSI (VT100 is extension of the ANSI spec).

    >Also included on the board is emulation for the altair disk drive and
    >support for 8MB disks via MMC/SD cards.


    Cool! I found CF cards to be easier. The 8bit transfers and LBA
    modes save a lot of work.

    >The ethernet decoder is an STA013. I wanted to use the MAS3507D
    >because I have a lot of those things laying around, but they don't
    >appear to be in production any more.


    Common problem. By time you can get them the EOL message is
    on the net.

    >I built an interface for the S100 bus that has a 32k SRAM buffer. This
    > provides up to 2 seconds of buffer time for a 128kbit MP3. A
    >"regular" 128kbit MP3 only requires 16kbyte/sec.


    Within the bandwidth of a lightly loaded Z80 doing limited processing.

    >Of course the altair can't actually decode the MP3 itself, I'm not
    >crazy...


    Altair was 8080 at 2mhz, now there's running only one leg.

    >I will post full specs in a second...


    Ok!

    Allison

  10. Re: MP3s and Ethernet

    > What part of all that said you already did it? Sounded more like
    > "hey anyone doing this?".


    Its real easy to organize parts on a PCB...software development is much
    harder IMO...

    > sorta what I expected, PC tech on an S100 card, but what functions are
    > the things on the s100 side doing for you?


    The whole UDP/IP stack and data transfer routines to the mp3 decoder.
    I know, its just an exercise in reading and writing bytes, but at least
    its fun and interesting!

    > Suggestion do VT52, vt100 is far more complex and few implmentations
    > are even close to right. (VT100 does 132 char and 40char doublewidth
    > and height (12 lines)). What usually ends up being build is 80x25
    > with base ANSI (VT100 is extension of the ANSI spec).


    Sure. Any other ideas? I designed the card with two dip switches to
    select the terminal mode. So I could have up to 4 modes. Straight
    ADM-3, VT52, ?, ?.

    > Cool! I found CF cards to be easier. The 8bit transfers and LBA
    > modes save a lot of work.


    CF would have been a LOT easier for a pure Altair<->flash interface.
    But I wanted to emulate the Altair Disk drive, so I needed to interface
    the flash to an AVR. Its very easy to interface the MMC/SD card to an
    AVR. The AVR pretends to be the altair disk drive and "translates"
    between the two. I'm including a mode for the Altair to directly
    control the MMC/SD card for large CP/M partitions.

    This disk setup will be fairly slow compared to a compact flash
    interface because of the wait states needed. Even a 16MIPS AVR has
    trouble providing data for the Altair on time. 1 to 2 wait states is
    common...

    I plan to have a high density RAM and IDE (compact flash) card in the
    future. I just ran out of space on this card to include IDE.

    > >I built an interface for the S100 bus that has a 32k SRAM buffer. This
    > > provides up to 2 seconds of buffer time for a 128kbit MP3. A
    > >"regular" 128kbit MP3 only requires 16kbyte/sec.

    >
    > Within the bandwidth of a lightly loaded Z80 doing limited processing.


    Now what would be the "best" setup for this is an extremely limited
    program running on the Altair. I have been investigating the
    possibilities of creating a plug in for WinAMP that instead of decoding
    the MP3 file opens a socket and sends the data to the Altair. There
    are even plugins available for WinAMP that allow control of the main
    functions of WinAMP. Extended support could even be controlling the
    operation of winamp from the S-100 computer.

    Of course any player could be used. For at least a month or two I will
    not have enough time to do more than create a console program. THIS is
    where I wanted help.


  11. Re: MP3s and Ethernet

    On 24 Aug 2006 11:09:15 -0700, "logjam" wrote:

    >> Suggestion do VT52, vt100 is far more complex and few implmentations
    >> are even close to right. (VT100 does 132 char and 40char doublewidth
    >> and height (12 lines)). What usually ends up being build is 80x25
    >> with base ANSI (VT100 is extension of the ANSI spec).

    >
    >Sure. Any other ideas? I designed the card with two dip switches to
    >select the terminal mode. So I could have up to 4 modes. Straight
    >ADM-3, VT52, ?, ?.


    H19 and Telvideo 950 are possible choices.

    >> Cool! I found CF cards to be easier. The 8bit transfers and LBA
    >> modes save a lot of work.

    >
    >CF would have been a LOT easier for a pure Altair<->flash interface.
    >But I wanted to emulate the Altair Disk drive, so I needed to interface
    >the flash to an AVR. Its very easy to interface the MMC/SD card to an
    >AVR. The AVR pretends to be the altair disk drive and "translates"
    >between the two. I'm including a mode for the Altair to directly
    >control the MMC/SD card for large CP/M partitions.


    the AVR has more horsepower than the 8080 by a longshot.
    I'd have considered programming the AVR to emulate an 8080.

    >This disk setup will be fairly slow compared to a compact flash
    >interface because of the wait states needed. Even a 16MIPS AVR has
    >trouble providing data for the Altair on time. 1 to 2 wait states is
    >common...


    Ick bad. When I said slow earlier I was refering to what the storage
    device could do as the CPU speed was the limiting factor.

    >I plan to have a high density RAM and IDE (compact flash) card in the
    >future. I just ran out of space on this card to include IDE.


    With current memory tech its easy to do. It's easier to design a
    whole CPU and put the ram on the same card with basic IO and
    other handy stuff.

    >> >I built an interface for the S100 bus that has a 32k SRAM buffer. This
    >> > provides up to 2 seconds of buffer time for a 128kbit MP3. A
    >> >"regular" 128kbit MP3 only requires 16kbyte/sec.

    >>
    >> Within the bandwidth of a lightly loaded Z80 doing limited processing.

    >
    >Now what would be the "best" setup for this is an extremely limited
    >program running on the Altair. I have been investigating the
    >possibilities of creating a plug in for WinAMP that instead of decoding
    >the MP3 file opens a socket and sends the data to the Altair. There
    >are even plugins available for WinAMP that allow control of the main
    >functions of WinAMP. Extended support could even be controlling the
    >operation of winamp from the S-100 computer.


    The 8080 could do low speed controls and user interface work.
    Other than that I'd do my best to keep it out of the way.
    Altair while the first S100 is also not a representitive example of
    S100 during most of it's lifetime. Even the IMSAI was an improvement
    and proved a more robust machine over time. The typical Altair often
    had a Z80 card substituted and most Altair disks systems failed within
    a few years leading to upgrades there as well. I have two, ones a
    fully functional museam peice and the other is the one I built in '75
    and made it to 76 before being severly upgraded and later retired
    (I still have it).

    Generally when I play on S100 (I do so fairly often) I start with 4mhz
    Z80s. At 4mhz I'm playing with the better Z80 cards stock that
    have things like rom, POJ, POR built in. The modded cards are
    running 8 and 10mhz z80s with suitably fast ram. My typical S100
    crate ( I have 6 operational) are experiments in pushing
    performance limits for 8bitters.

    I have one (NS* crate) I've use for over two decades that still earns
    it's keep(cross assemblers, Eprom burner, EEprom toaster, Eprom
    emulator and serialbus host. .

    >Of course any player could be used. For at least a month or two I will
    >not have enough time to do more than create a console program. THIS is
    >where I wanted help.


    Not my range of interest. I still play vinyl and .25" tape. As to
    networking the easiest solution was a 486 brick PC running IP
    to whatever gateway/bridging.

    Allison

  12. Re: CP/M harddrive emulation on a PC connected with a real CP/M computer

    nospam@nouce.bellatlantic.net wrote:
    > On Thu, 24 Aug 2006 15:20:09 +0200, "Peter Dassow (remove the NOSPAM.
    > for direct answer)" wrote:
    >
    >> To be honest: I've some considerations already done about a cheap
    >> network solution, but not full-featured, instead, just to connect a mass
    >> storage via a network-alike connection. My idea was to change an already
    >> existing RAMDISK source for CP/M to a virtual drive solution via the
    >> parallel port.

    >
    > This has been done via serial port. There is at least one
    > commercial one Filink (for epsom PX8) that used a CP/M system as a
    > host.
    >

    Allison, thank you for your helpful comment.
    Unfortunately the serial port of the CP/M systems I know are limited to
    9600 Baud, or, if really fast, to 19200 Baud.
    This is painful slow for disk access functions.

    > I started doing this back in '81 so some of my non-disk equipped
    > sytems could use another cpm system as a host via serial line. The
    > code was system specific to my hardware but in general form it's
    > Client BIOS to serial and serial to BIOS on Host. If you ever worked
    > with a CP/M BIOS you know thats where CP/M expects all it's logical
    > requests to be translated to hardware action (abstraction layer).
    > So a BIOS can literally interface to anything that can simulate a
    > block addressable storage. Adding a serial line or parallel line
    > in the middle of that is strictly a transport issue.


    That's true, it should be no real issue to implement a "transport" layer.

    >> On the other side should be a (even old) PC, which emulates a CP/M
    >> harddisk (means, this PC side will offer a 8 or 512 MB HD in a low level
    >> sector manner, which would be a container file on a PC harddisk.
    >> This project should be easily implemented for me in the next time, but
    >> my first problem is not the knowledge, instead the missing time :-(

    >
    > FYI: CP/M (Not any of the enhanced versions like CP/M3 or Zrdos)
    > is limited to 8mb logical disks (65535x128 byte sectors) and 16 disks
    > maximum. The Improved versions can address up to 2GB but with a flat
    > file system and fixed directory size anything over 32mb would not be
    > as useful as smaller partitions. There are some system management
    > issues there.


    That's why I mentioned both limits, 8 MB and 512 MB - 8 MB for CP/M 2.2
    and 512 MB for CP/M 3 aka Plus. I do not know any 2 GB limit for CP/M
    (instead, this sounds familiar to old DOS versions), because any
    extension beside the standard is not portable to other CP/M systems
    (exception: the Z-Systems).

    > Disk emulation via PC is straightforward (use dos or linux for less
    > pain). All you need is a fixed size file file whose content is a cpm
    > file structure and a way to communicate with the CP/M system. That
    > means a CBIOS that knows the transport (serial, parallel or Vodoo)
    > media it's protocal (can be homebrewed) and can effectively transmit
    > requests for DRIVE, TRACK, SECTOR (and 128 bytes of data
    > for a write) to the host and the host needs to translate that to
    > reading and writing within the "container file" and transmiting the
    > results back (which may only be status for a write). The container
    > file for all intents is a database with the content being "directory"
    > or "data". The details of CP/M file system and it's ODS is
    > documented so there no secret and how the CP/M systems bios
    > works is documented.


    Yes, it could be done. But - I already told that, you need still time...

    Peter
    --
    My new project: Try http://www.z80.eu for CP/M computer infos.

  13. Re: MP3s and Ethernet

    > the AVR has more horsepower than the 8080 by a longshot.
    > I'd have considered programming the AVR to emulate an 8080.


    The AVR isn't fast enough to emulate the actual instruction timing or
    I/O. It might run the code, but not at the same pace. Even the FPGA
    cores out there don't completely emulate an 8080. I've considered a
    single board Altair like that, but it would take a LOT of work to make
    it just right.

    And when all said and done, it probably would make enough interference
    to play "Fool On the Hill"...

    > Ick bad. When I said slow earlier I was refering to what the storage
    > device could do as the CPU speed was the limiting factor.
    >
    > >I plan to have a high density RAM and IDE (compact flash) card in the
    > >future. I just ran out of space on this card to include IDE.

    >
    > With current memory tech its easy to do. It's easier to design a
    > whole CPU and put the ram on the same card with basic IO and
    > other handy stuff.


    I wanted the board to be easy for anyone to assemble. All the chips
    but two are standard .100 DIP parts. The 8pin DAC and 24? pin STA013.
    Every other part is through hole

    There really isn't anything on the card that wouldn't be required on
    combination CPU / I/O card. The CPLD wouldn't have to be quite as
    complex, but all of the I/O devices would still require it.

    The CPLD is even required to assert the RDY line since the AVR isn't
    fast enough to generate it at the right time every time. The AVR sends
    a signal to the CPLD when its done and the CPLD releases RDY.

    The CPLD handles the read and write signal buffers too, which is why
    the "enable" 2SIO/MP3/DSK jumpers are needed. If you had a real 2SIO
    and didn't want to use the fake one then you would have to tell the
    CPLD NOT to make the write buffer active. That could cause some buffer
    smoke!

    > had a Z80 card substituted and most Altair disks systems failed within
    > a few years leading to upgrades there as well. I have two, ones a
    > fully functional museam peice and the other is the one I built in '75
    > and made it to 76 before being severly upgraded and later retired
    > (I still have it).


    What was the most common failure of a disk system? Mine works fine
    other than it has to "warm" up before it will work. This could be the
    PROM card though... I've read about 20 disks with it at least. The
    thing I was worrying about was wearing out the head. It has to load
    the head every 4 sectors which is 616 kaplinks per disk!!!

    Mine would probably be a museum piece too if someone hadn't painted it
    black and mounted it in a rack enclosure... Still boots disk basic and
    plays startrek like new.

    Grant


  14. Re: CP/M harddrive emulation on a PC connected with a real CP/M computer

    On Thu, 24 Aug 2006 22:27:10 +0200, "Peter Dassow (remove the NOSPAM.
    for direct answer)" wrote:

    >nospam@nouce.bellatlantic.net wrote:
    >> On Thu, 24 Aug 2006 15:20:09 +0200, "Peter Dassow (remove the NOSPAM.
    >> for direct answer)" wrote:
    >>
    >>> To be honest: I've some considerations already done about a cheap
    >>> network solution, but not full-featured, instead, just to connect a mass
    >>> storage via a network-alike connection. My idea was to change an already
    >>> existing RAMDISK source for CP/M to a virtual drive solution via the
    >>> parallel port.

    >>
    >> This has been done via serial port. There is at least one
    >> commercial one Filink (for epsom PX8) that used a CP/M system as a
    >> host.
    >>

    >Allison, thank you for your helpful comment.
    >Unfortunately the serial port of the CP/M systems I know are limited to
    >9600 Baud, or, if really fast, to 19200 Baud.
    >This is painful slow for disk access functions.


    Most will go faster, t's a programming problem and often the BRG is
    not there to provide more.

    My NS* easily does 38.4 and ome of the Compupro cards can beat that.
    In any case it's S100 so a board that can makes it a moot point.

    However, that aside even at 19,200 most CP/M programs are not that bad
    as average size is around 12k.

    >> I started doing this back in '81 so some of my non-disk equipped
    >> sytems could use another cpm system as a host via serial line. The
    >> code was system specific to my hardware but in general form it's
    >> Client BIOS to serial and serial to BIOS on Host. If you ever worked
    >> with a CP/M BIOS you know thats where CP/M expects all it's logical
    >> requests to be translated to hardware action (abstraction layer).
    >> So a BIOS can literally interface to anything that can simulate a
    >> block addressable storage. Adding a serial line or parallel line
    >> in the middle of that is strictly a transport issue.

    >
    >That's true, it should be no real issue to implement a "transport" layer.


    There isn't. Though you do need some protocal to manage who talks
    first and error checks.

    For the serial case I used simple ready request with ack/nak.


    At the BIOS level the transfer is fairly likely one of two size
    packets. Read request (drive, track, sector [or LBA]).
    Write adds 128 bytes of data to that (drive, track, sector [or LBA],
    128 data). at worst the transfer is around 133bytes
    (R/Wbyte,D,T,S,128D,C)
    with a check byte and the wrapper is to sync both ends.

    Think of it as:

    Hey you!
    Ya!
    hercomes (blat)
    [depending on request]
    Yes, no(error blat), read response (blat)

    >>> On the other side should be a (even old) PC, which emulates a CP/M
    >>> harddisk (means, this PC side will offer a 8 or 512 MB HD in a low level
    >>> sector manner, which would be a container file on a PC harddisk.
    >>> This project should be easily implemented for me in the next time, but
    >>> my first problem is not the knowledge, instead the missing time :-(

    >>
    >> FYI: CP/M (Not any of the enhanced versions like CP/M3 or Zrdos)
    >> is limited to 8mb logical disks (65535x128 byte sectors) and 16 disks
    >> maximum. The Improved versions can address up to 2GB but with a flat
    >> file system and fixed directory size anything over 32mb would not be
    >> as useful as smaller partitions. There are some system management
    >> issues there.

    >
    >That's why I mentioned both limits, 8 MB and 512 MB - 8 MB for CP/M 2.2
    >and 512 MB for CP/M 3 aka Plus. I do not know any 2 GB limit for CP/M
    >(instead, this sounds familiar to old DOS versions), because any
    >extension beside the standard is not portable to other CP/M systems
    >(exception: the Z-Systems).


    Even at 8mb thats fair amount of space. And you not limited to one.
    Also it is possible to have the host software point to multiple
    selectable container files as sims already do.

    P2DOS, novados, and a slew of others based on P2DOS ideas
    fixed the math so that the limit is 65535* allocation block size
    (up to 32k) rather than overflowing on sector size. Since CP/M
    assembles sectors into groups of allocation blocks it makes
    sense even with 16bit math. Makes for much larger limits.

    >> Disk emulation via PC is straightforward (use dos or linux for less
    >> pain). All you need is a fixed size file file whose content is a cpm
    >> file structure and a way to communicate with the CP/M system. That
    >> means a CBIOS that knows the transport (serial, parallel or Vodoo)
    >> media it's protocal (can be homebrewed) and can effectively transmit
    >> requests for DRIVE, TRACK, SECTOR (and 128 bytes of data
    >> for a write) to the host and the host needs to translate that to
    >> reading and writing within the "container file" and transmiting the
    >> results back (which may only be status for a write). The container
    >> file for all intents is a database with the content being "directory"
    >> or "data". The details of CP/M file system and it's ODS is
    >> documented so there no secret and how the CP/M systems bios
    >> works is documented.

    >
    >Yes, it could be done. But - I already told that, you need still time...


    Ya! I always said if I had both time and money at the same time I'd
    be dangerous.


    Allison

  15. Re: MP3s and Ethernet

    On 24 Aug 2006 13:39:59 -0700, "logjam" wrote:

    >> the AVR has more horsepower than the 8080 by a longshot.
    >> I'd have considered programming the AVR to emulate an 8080.

    >
    >The AVR isn't fast enough to emulate the actual instruction timing or
    >I/O. It might run the code, but not at the same pace. Even the FPGA
    >cores out there don't completely emulate an 8080. I've considered a
    >single board Altair like that, but it would take a LOT of work to make
    >it just right.


    Your kidding, poor design as I did it in 2901s and ttl many years ago
    and hit 4mhz. Doesn't take much to beat a 8080!

    >And when all said and done, it probably would make enough interference
    >to play "Fool On the Hill"...


    Why not the original did!

    >> Ick bad. When I said slow earlier I was refering to what the storage
    >> device could do as the CPU speed was the limiting factor.
    >>
    >> >I plan to have a high density RAM and IDE (compact flash) card in the
    >> >future. I just ran out of space on this card to include IDE.

    >>
    >> With current memory tech its easy to do. It's easier to design a
    >> whole CPU and put the ram on the same card with basic IO and
    >> other handy stuff.

    >
    >I wanted the board to be easy for anyone to assemble. All the chips
    >but two are standard .100 DIP parts. The 8pin DAC and 24? pin STA013.
    >Every other part is through hole


    Reasonable. The POJ and POR however is on most cpu cards or the
    frontpannel where it exists.

    >There really isn't anything on the card that wouldn't be required on
    >combination CPU / I/O card. The CPLD wouldn't have to be quite as
    >complex, but all of the I/O devices would still require it.
    >
    >The CPLD is even required to assert the RDY line since the AVR isn't
    >fast enough to generate it at the right time every time. The AVR sends
    >a signal to the CPLD when its done and the CPLD releases RDY.


    Inwait hardware. I do it with a few gates. Bad juju if the Altair is
    using 88S or 88MCD series dynamic memory as they sometimes
    forget to refresh.

    >The CPLD handles the read and write signal buffers too, which is why
    >the "enable" 2SIO/MP3/DSK jumpers are needed. If you had a real 2SIO
    >and didn't want to use the fake one then you would have to tell the
    >CPLD NOT to make the write buffer active. That could cause some buffer
    >smoke!


    Sounds convoluted.

    >> had a Z80 card substituted and most Altair disks systems failed within
    >> a few years leading to upgrades there as well. I have two, ones a
    >> fully functional museam peice and the other is the one I built in '75
    >> and made it to 76 before being severly upgraded and later retired
    >> (I still have it).

    >
    >What was the most common failure of a disk system? Mine works fine
    >other than it has to "warm" up before it will work. This could be the
    >PROM card though... I've read about 20 disks with it at least. The
    >thing I was worrying about was wearing out the head. It has to load
    >the head every 4 sectors which is 616 kaplinks per disk!!!


    For Altairs it was the drives, mechanical and electrical failures from
    heat. Never seen a head wear out. positioners get sloppy, head load
    pads, unglue and hub clamp rings get brittle and die.

    >Mine would probably be a museum piece too if someone hadn't painted it
    >black and mounted it in a rack enclosure... Still boots disk basic and
    >plays startrek like new.


    Mine even has the "Altair business systems" desk with the side rack.
    Runs great but slower than sludge.


    Allison

  16. Re: MP3s and Ethernet

    > >The CPLD is even required to assert the RDY line since the AVR isn't
    > >fast enough to generate it at the right time every time. The AVR sends
    > >a signal to the CPLD when its done and the CPLD releases RDY.

    >
    > Inwait hardware. I do it with a few gates.


    Same with me. But if I were using TTL for everything on the card it
    would be quite a bit bigger.

    Without the CPLD the card would be completely unflexible. Of course
    everything done on my board could be made with a bunch of gates and
    flip flops, but it would take a second S-100 card for it all. The
    AVR decides how many wait states it needs. The first access of a
    sector will take longer than the remaining bytes. No wait states are
    required for RAM/EEPROM/Flash/Ethernet, just the AVR junk...

    > >The CPLD handles the read and write signal buffers too, which is why
    > >the "enable" 2SIO/MP3/DSK jumpers are needed. If you had a real 2SIO
    > >and didn't want to use the fake one then you would have to tell the
    > >CPLD NOT to make the write buffer active. That could cause some buffer
    > >smoke!

    >
    > Sounds convoluted.


    Not really. It actually speeds up transfers by an average of 10%. The
    AVR needs as much time as it can get for its own software tasks. Let
    the CPLD worry about which device is being addressed and when to assert
    the buffers. And if the AVR should crash some day...well, lets just
    say the 8T97 has won wars against a LS376...

    Right now the CPLD decodes a 2SIO I/O address for example. It sets a
    RD/WR line for the AVR and then asserts a chip select to interrupt the
    AVR. The AVR checks A0-A3 and either inputs data or outputs depending
    on RD/WR. When the chip select is cleared, if it was an output
    operation the AVR gives up the card bus.

    I am open to any suggestions for improvements. But remember that all
    the memories and I/O devices have to be able to assert the buffers.
    Why not just do it with the CPLD?

    I interfaced a Scenix SX to the ISA bus once and it was a major
    headache to do without wait states. I considered using a Scenix in
    this project, but they are noisy and I didn't really like them that
    much. I think I had it going at around 16Mbyte/s before I gave up


  17. Re: MP3s and Ethernet

    nospam@nouce.bellatlantic.net wrote:
    >
    > On Thu, 24 Aug 2006 10:48:01 +0200, "French Luser"
    > wrote:
    >
    > >"logjam" wrote:
    > >
    > >> (...) It would be easier if some developers out
    > >> there had too much spare time and money.

    > >
    > >Grant, in case you have not yet understood after all this time, if you don't
    > >do something by yourself, alone, nobody else will do it. (In addition, if you
    > >do something, some people will critic you...)

    >
    > Some people that have no concept of what kind of processing is
    > required to do MP3 or Eitherneta(at eithernet speeds) will encourage
    > you.
    >
    > In the age of super fast cpus and huge memories in the sub 10ns range
    > it's easy to forget what it takes to decompress MP3 or assemble
    > eithenet packets even at the lowly 10mb/S rate.

    --------------------------------
    Sure, BUT: We must remember that IF we knew THEN what we know NOW,
    that people could have built a man-powered aircraft in the 1500's!

    There is something to be said for taking a thoroughly modern project
    back through a retro-development "what-if" with primitive technology!

    -Steve
    --
    -Steve Walz rstevew@armory.com ftp://ftp.armory.com/pub/user/rstevew
    Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
    http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public

  18. Re: MP3s and Ethernet

    > Sure, BUT: We must remember that IF we knew THEN what we know NOW,
    > that people could have built a man-powered aircraft in the 1500's!
    >
    > There is something to be said for taking a thoroughly modern project
    > back through a retro-development "what-if" with primitive technology!


    I think the same thing about computers. When were relays available???

    I have a TTL databook from 75 and designed (in schematic) a 32 bit RISC
    TTL computer with a 64 bit ALU. My reason for building such a thing
    would be "to proove it could have been done", and because its just
    amazing watching a pile of gates do something. Even though the whole
    thing could be in an FPGA, its just hard to wrap your head around.

    I spent a while trying to calculate how many of these TTL computers
    would be required to play an MP3. I think it will take at least 3, and
    maybe a 4th for data collection. The only part of the computer I've
    tested is the ALU. It was completely combinatorial. 32bit x 32bit in
    one instruction cycle. Thats about as fast as a 50MHz 486 for
    multiplying!

    Grant


+ Reply to Thread