5 Feb
2014
5 Feb
'14
2:16 a.m.
Greetings,
I've been hard at work on an OS/8 system handler that negotiates block
transfers between a PC running a special disk server. The two are currently
working great! I was able to use the BUILD utility to make my own OS/8 V3D
disk and boot from it. I then thought that it may be possible to take an
existing RK05 image and replace the bootloader and system handler with my
own. Sure enough, it works!
Check it out: https://www.youtube.com/watch?v=YkqVJ6ShV5A
I'll be releasing the source code for all of this within the next few weeks
as I make minor changes (and mostly tidy it up).
A few details: the handler resides in one page and talks to the server to
negotiate the transferring of pages. To keep the handler small, I'm
offloading as much stuff onto the PC as possible. There's no error
detecting (although this hasn't been an issue for the millions of bits I've
sent thus far) and the features of the handler are pretty basic. The disk
server is written entirely in C and has been successfully compiled on Mac
OS X and Windows under Cygwin.
The handler sends serial data to an M8650YA (currently addressed at 40/41,
the aux TTY addresses) operating at 19200 baud. This is pretty slow still,
as you can see from the video. But it's usable! And it's bound to get
better with a few more improvements.
To bootstrap the system, the RIM loader is toggled in as the primary
bootloader, and a secondary bootloader is sent in RIM format. Start the
system at 0020 after that, and it'll boot right up.
In summary, anyone with a spare M8650, M8655, or other serial card can now
boot OS/8, even if you don't have an RK05, DECtape, RX01/02, etc.! If you
have a parallel I/O card, another handler could be made for even faster
transfers, I imagine. This would require some extra hardware, though.
Let me know if you have any questions. Again, I'll see about distributing
the source in a couple of weeks, or as I have time.
Kyle
5 Feb
5 Feb
7:46 p.m.
On Wed, 5 Feb 2014 01:16:03 -0600
Kyle Owen <kylevowen at gmail.com> wrote:
Greetings,
I've been hard at work on an OS/8 system handler that negotiates block
transfers between a PC running a special disk server. The two are
currently working great! I was able to use the BUILD utility to make
my own OS/8 V3D disk and boot from it. I then thought that it may be
possible to take an existing RK05 image and replace the bootloader
and system handler with my own. Sure enough, it works!
Check it out: https://www.youtube.com/watch?v=YkqVJ6ShV5A
I'll be releasing the source code for all of this within the next few
weeks as I make minor changes (and mostly tidy it up).
Great! This ought to work with Philipp Hachtmann's "Omni-USB" board for
really fast I/O. When you release the driver, I'll check out it's
performance - RK05 vs. Serial/USB.
--snip--
The handler sends serial data to an M8650YA (currently
addressed at
40/41, the aux TTY addresses) operating at 19200 baud. This is pretty
slow still, as you can see from the video. But it's usable! And it's
bound to get better with a few more improvements.
BTW: Omni-USB defaults to these ports...
--snip--
Cheers,
Lyle
--
Bickley Consulting West Inc.
http://bickleywest.com
"Black holes are where God is dividing by zero"
6 Feb
6 Feb
8:19 a.m.
Am 06.02.2014 01:46, schrieb Lyle Bickley:
Great! This ought to work with Philipp Hachtmann's
"Omni-USB" board for
really fast I/O. When you release the driver, I'll check out it's
performance - RK05 vs. Serial/USB.
I waited for this comment, hehe :-)
And be sure: If you release your software, I'll try it out.
I see that you use Windows on the server side - I don't have Windows :-(
Does it run under Linux as well? Or is the core functionality encapsuled
platform independent? Or do I have to make a Linux version?
BTW: Omni-USB defaults to these ports...
Of
course - these are the ports I used for PC communication before
OmniUSB :-)
Kind regards
Philipp
11:04 a.m.
On Thu, Feb 6, 2014 at 8:19 AM, Philipp Hachtmann <hachti at hachti.de> wrote:
And be sure: If you release your software, I'll
try it out.
I see that you use Windows on the server side - I don't have Windows :-(
Nor I, but I'm excited by the possibility of this driver. In a way,
it's like the old attempts to implement an OS/8 TU58 handler when it
was new, but without needing to implement a BREAK to get the storage
device's attention.
Does it run under Linux as well? Or is the core
functionality encapsuled
platform independent? Or do I have to make a Linux version?
I'd love to see this running on a Raspberry Pi (using the built-in
serial port with a level shifter not a USB serial dongle). _I_ would
be happy to set up and test that.
Another variant I'd like to try is bringing this up on a DECmate I
with a DP278. I know it's not _exactly_ like a KL8E, but hopefully
the differences are minor enough that the handler is still one page.
Also, since there is a DKC8AA most PDP-8/a boxes that is rarely used
(sometimes, people use it to drive a line printer instead of buying an
LP8E card - there's an OS/8 handler for that), I look forward to a
parallel-port version of this - even if it takes a $25 microcontroller
to handle the low-level transfers.
-ethan
12:32 p.m.
On Thu, Feb 6, 2014 at 10:04 AM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
Another variant I'd like to try is bringing this up on a DECmate I
with a DP278. I know it's not _exactly_ like a KL8E, but hopefully
the differences are minor enough that the handler is still one page.
I've got a few spare locations in the handler. I'll look into the DP278 and
see what I can do. I may also write an optimized handler for Philipp's
Omni-USB board.
Also, since there is a DKC8AA most PDP-8/a boxes that is rarely used
(sometimes, people use it to drive a line printer
instead of buying an
LP8E card - there's an OS/8 handler for that), I look forward to a
parallel-port version of this - even if it takes a $25 microcontroller
to handle the low-level transfers.
Yes, I had considered a parallel version, but I only have 12-bit parallel
output cards, not any I/O cards...but for an -8/A, that sounds like a fine
alternative. The external hardware could be a minimal 16-bit
microcontroller, I imagine.
Also, I had considered a handler version that operates on address 03/04 by
using some clever escape sequences, much like AT modem commands. You'd need
to use it with a special terminal program, or modify the server to output
non-handler messages to a pseudo-TTY that another terminal emulator is
connected to. This way, *anyone* with a PDP-8 that has just one
asynchronous serial card can boot OS/8!
What do you all think? What would a good choice be for an escape sequence?
It could have a time component in there as well so the symbol rate becomes
part of the "signature" of the sequence.
Kyle
4:09 p.m.
I'd love to see this running on a Raspberry Pi
(using the built-in
serial port with a level shifter not a USB serial dongle). _I_ would
be happy to set up and test that.
Great minds think alike, or soemthing. I have jsut suggested the same
thing. FOr all my 8/e has a PC04, TU56, RX01 and an RK8E controlelr with
no drives currently conencted, I migth stil lgive this a go. But I am not
the one to write the esoftware...
-tony
12:24 p.m.
On Thu, Feb 6, 2014 at 7:19 AM, Philipp Hachtmann <hachti at hachti.de> wrote:
And be sure: If you release your software, I'll try it out.
That's a when, not an if! :) I'm improving it right now for a faster
transfer stream. I hope to have something official by the beginning of next
week at the latest.
I see that you use Windows on the server side - I
don't have Windows :-(
Does it run under Linux as well? Or is the core functionality encapsuled
platform independent? Or do I have to make a Linux version?
I wrote this with Linux in mind, in fact. I wrote this entirely in C, and
it compiles under gcc for both Mac OS X and Cygwin. I don't have a native
DOS/Windows version, and I don't intend to support one at this time.
So rest assured, everyone: it will is supported on Linux, Mac OS X and
Windows under Cygwin.
I intend to bring out the Raspberry Pi shortly. The only downside is that
the USB functionality is hindered greatly by the fact that both USB ports
and the Ethernet port all tie into the same bus. Also, I don't mind running
headless, but with both USB ports taken up by USB-serial converters, I
won't have a spot for a flash drive. Either I'll map a network drive or
just suffer with using the SD card. Then again, if I use a real man's
terminal, I'll save a USB port! :)
My other goal is to compile this for an Arduino (or compatible) and have a
"hands-free" version that can sit nicely in the case of the PDP-8 and not
require any external maintenance. I fear though that I won't have enough
RAM in the Arduino to buffer the input stream. I may have to handicap the
handler a bit to fix that.
Kyle
1:37 p.m.
On Feb 6, 2014, at 12:24 PM, Kyle Owen <kylevowen at gmail.com> wrote:
My other goal is to compile this for an Arduino (or
compatible) and have a
"hands-free" version that can sit nicely in the case of the PDP-8 and not
require any external maintenance. I fear though that I won't have enough
RAM in the Arduino to buffer the input stream. I may have to handicap the
handler a bit to fix that.
If you're really worried about it on the Arduino (how much buffer do
you really need, anyway?), you could always try bare-metal on something
a little beefier. I highly recommend the STM32F4DISCOVERY board, which
works very nicely with the GCC ARM stack; it has a companion baseboard
which adds an RS232-converted serial port (as opposed to bare CMOS
levels), an Ethernet port and a microSD slot. I'll be glad to help you
get up and running with it; there's a great Launchpad project that
maintains Mac/Windows/Linux binaries for a targeted GCC stack plus a
micro version of Newlib, the C library. Really neat stuff.
- Dave
2:50 p.m.
On Thu, Feb 6, 2014 at 12:24 PM, Kyle Owen <kylevowen at gmail.com> wrote:
I intend to bring out the Raspberry Pi shortly. The
only downside is that
the USB functionality is hindered greatly by the fact that both USB ports
and the Ethernet port all tie into the same bus.
True.
Also, I don't mind running
headless, but with both USB ports taken up by USB-serial converters, I
won't have a spot for a flash drive. Either I'll map a network drive or
just suffer with using the SD card. Then again, if I use a real man's
terminal, I'll save a USB port! :)
I recommend using that real serial port for the connection to the
PDP-8. You could ssh into the R-Pi for control or, for a follow-on
product, it's not hard to stick a textual LCD and a couple of buttons
onto the GPIO header. You can even get them as a pre-assembled
shield.
My other goal is to compile this for an Arduino (or
compatible) and have a
"hands-free" version that can sit nicely in the case of the PDP-8 and not
require any external maintenance.
I love the idea.
I fear though that I won't have enough
RAM in the Arduino to buffer the input stream. I may have to handicap the
handler a bit to fix that.
The lack of RAM in the smaller AVR chips _is_ an impediment. The
larger chips have 4K or even up to 8K of onboard SRAM (up from 1K or
2K), or alternately, some people have had good success with SPI or I2C
RAM. It is likely to be fast enough to buffer incoming packets at
the cost of a few bucks on top of the AVR. Consider, for example, the
ATmega644P or ATmega1284P - as seen in the Sanguino. They have 2
internal UARTs (no serial bitbanging required) and 4K of SRAM. They
come in 40-pin-DIP and 44-pin TQFP, IIRC.
-ethan
5:15 p.m.
On Thu, Feb 6, 2014 at 1:50 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote:
I recommend using that real serial port for the connection to the
PDP-8. You could ssh into the R-Pi for control or, for a follow-on
product, it's not hard to stick a textual LCD and a couple of buttons
onto the GPIO header. You can even get them as a pre-assembled
shield.
My plan was to use a USB-serial converter for the disk server, a glass
terminal (not the RPi) for TTY: (or another laptop, to make file transfers
easy), and a USB thumb drive to store the data on. Is this what you're
thinking too?
Were you saying that utilities like tcpser to link the RPi to another
machine running the server would not be a good idea?
The lack of RAM in the smaller AVR chips _is_ an
impediment. The
larger chips have 4K or even up to 8K of onboard SRAM (up from 1K or
2K), or alternately, some people have had good success with SPI or I2C
RAM. It is likely to be fast enough to buffer incoming packets at
the cost of a few bucks on top of the AVR. Consider, for example, the
ATmega644P or ATmega1284P - as seen in the Sanguino. They have 2
internal UARTs (no serial bitbanging required) and 4K of SRAM. They
come in 40-pin-DIP and 44-pin TQFP, IIRC.
On Thu, Feb 6, 2014 at 12:37 PM, David Riley <fraveydank at gmail.com> wrote:
If you're really worried about it on the Arduino (how much buffer do
you really need, anyway?), you could always try bare-metal on something
a little beefier. I highly recommend the STM32F4DISCOVERY board, which
works very nicely with the GCC ARM stack; it has a companion baseboard
which adds an RS232-converted serial port (as opposed to bare CMOS
levels), an Ethernet port and a microSD slot. I'll be glad to help you
get up and running with it; there's a great Launchpad project that
maintains Mac/Windows/Linux binaries for a targeted GCC stack plus a
micro version of Newlib, the C library. Really neat stuff.
I have quite a few development boards around here, including a Mojo FPGA
board, many Arduinos, a couple of Teensy boards, and as of two days ago, an
STM32F4DISCOVERY. The DISCOVERY is actually for my embedded systems class,
so I'll be playing with that some this semester. Sounds like a fun project
to port the server over there. But David, I think I may take up your offer
in making a version for ARM; that board is cheap enough where I think a
viable product could be made from it, and eventually a standalone board
with some added peripherals.
In related news, I revamped my server and handler...I've quite literally
more than doubled the transfer rate. BASIC used to load in 13 seconds. I
now can load it in 6.3 seconds. It turns out much of the time was spent
handshaking between page transfers. Thus, long transfers were taking almost
as long as a small sequence of short transfers. Now, the handshaking is
only done at the beginning and end of the transfer, so the entire data
stream is uninterrupted from start to finish. Much faster for 31 block
transfers, for instance.
I have no idea how this will compare to an RK05...looking forward to
hearing some results from some benchmarks. I can probably modify some of my
regression tests to be a random disk read and sequential disk read to get
an idea of transfer rates between devices.
Here's my to do list before I feel comfortable releasing DiskServer v1.0:
- Clean up code (nearly done)
- Rewrite server to use dumprest format (very easy)
- Write README and a good tutorial
- Make program to replace bootloader and handler on disk packs (very easy)
- Non-system version (may take a little time)
- Check length of disk image on start
- Grow file system as writes occur
Things I'd like to do in the near future:
- Timeout within handler and server
- emulate RK05 disk pack (requires two entry points for two disk surfaces)
- Option to zero last 128 words in half block scenario (is this really
necessary?)
- ctrl-c operation (for non-system version)
Kyle
5:47 p.m.
On Thu, Feb 6, 2014 at 5:15 PM, Kyle Owen <kylevowen at gmail.com> wrote:
On Thu, Feb 6, 2014 at 1:50 PM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
I'm not sure we are talking about exactly the same thing.
What I was thinking about starts with an already-working PDP-8 setup.
One with a dumb terminal on it. It could either use a corner of its
SD card for disk image storage or a USB stick - that part isn't
relevant to how it works (it just affects how tightly coupled storage
is from operational software). There is already a serial port on the
R-Pi that doesn't use the same I/O channel as the USB interface, so
use _that_ for the disk server. If you want to talk to the R-Pi for
control or other functions, use a USB dongle there because the amount
of traffic is small and the USB overhead won't matter. For headless
operations, it's not difficult to put a textual LCD and navigation
buttons (to select and change the media presented to the PDP-8), and
it's not really much more expensive to put a graphical (NTSC) LCD on a
Pi - they come in 7" sizes for backup cameras and such.
Thinking back to TU-58 emulators, you just want a way to "switch
disks" - that can be done by interacting with the R-Pi on its own
console, via ssh or other remote protocol from a nearby PC, or by
directly-attached switches and textual output. It kind of depends on
how physically small you want to make the device and what sort of
physical UI you might prefer.
I recommend using that real serial port for the connection to the
PDP-8. You could ssh into the R-Pi for control or, for a follow-on
product, it's not hard to stick a textual LCD and a couple of buttons
onto the GPIO header. You can even get them as a pre-assembled
shield.
My plan was to use a USB-serial converter for the disk server, a glass
terminal (not the RPi) for TTY: (or another laptop, to make file transfers
easy), and a USB thumb drive to store the data on. Is this what you're
thinking too? Were you saying that utilities like tcpser to link the
RPi to another
machine running the server would not be a good idea?
I had no comment about that sort of arrangement.
... as of two days ago, an STM32F4DISCOVERY...
That looks interesting on the surface, and certainly cheap enough, but
what's the longevity? One advantage of using established tech
(Arduino/Sanguino/MEGA...) is the expectation that you'll be able to
find one in five years without having to reengineer the project for
whatever is running around by then. We are talking about a storage
emulator for a 1960s or 1970s computer where longevity is kind of the
point.
-ethan
7 Feb
7 Feb
3:41 a.m.
Am 06.02.2014 23:15, schrieb Kyle Owen:
I have no idea how this will compare to an
RK05...looking forward to
hearing some results from some benchmarks. I can probably modify some of my
regression tests to be a random disk read and sequential disk read to get
an idea of transfer rates between devices.
Sequential reading or writing of a whole RK05 (without obtainining resp.
depositing the data on the 8) takes approx. 45 seconds.
3:43 a.m.
Am 06.02.2014 23:15, schrieb Kyle Owen:
Here's my to do list before I feel comfortable
releasing DiskServer v1.0:
- Rewrite server to use dumprest format (very easy)
Good idea!
- emulate RK05 disk pack (requires two entry points
for two disk surfaces)
Would be good.
- Option to zero last 128 words in half block scenario
(is this really
necessary?)
Don't think so.
:-)
6 Feb
6 Feb
3:06 p.m.
On Feb 6, 2014, at 12:24 PM, Kyle Owen <kylevowen at gmail.com> wrote:
...
I intend to bring out the Raspberry Pi shortly. The only downside is that
the USB functionality is hindered greatly by the fact that both USB ports
and the Ethernet port all tie into the same bus. Also, I don't mind running
headless, but with both USB ports taken up by USB-serial converters, I
won't have a spot for a flash drive. Either I'll map a network drive or
just suffer with using the SD card. Then again, if I use a real man's
terminal, I'll save a USB port! :)
You might check out the BeagleBone Black. It?s similar but the hardware is open (fully
documented in 4500 or so pages). I forgot just what the USB config looks like, but I do
remember that the stock board has a pair of USB ports plus Ethernet plus microSD, all
available at the same time. Oh yes, plus on-board flash so you don?t usually need the SD.
And several UARTs. There?s an off the shelf plugin board to provide RS232 level serial
I/O from any one of those UARTs. I did a 4 port RS232 level converter; design files
available if anyone wants them.
paul
3:44 p.m.
On Feb 6, 2014, at 3:06 PM, Paul Koning <paulkoning at comcast.net> wrote:
On Feb 6, 2014, at 12:24 PM, Kyle Owen <kylevowen at gmail.com> wrote:
The BBB is a nice device, but its bundled software is terrible enough
to turn me off of using the thing (and that's saying quite a bit; I'm
pretty tolerant of half-assery most of the time). My biggest complaint,
the one that's pretty much a dealbreaker to me, is that it won't boot
to the embedded flash if you have a uSD card inserted unless that card
is specially formatted to tell uBoot to ignore it. There's no flash
provided on the board to save parameters, so you can't save uBoot's
default boot device (which is hardwired to the uSD card), and instead
of moving on to the next device if booting from the uSD fails, uBoot
just hangs. There's no way to get around it short of rebuilding the
entire Linux and uBoot image and reflashing the whole embedded flash.
That prevents me from booting with (say) an unformatted uSD card in
there so that my unattended host platform can initialize it, which is
absolutely unacceptable. And the worst part was that I couldn't even
figure out why it wasn't booting until I put a serial->CMOS adaptor
on its debug port; the video isn't initialized at boot time, so there's
no status on the screen.
But it is nice hardware. I wish the software it came with wasn't quite
so boneheaded. As popular as the board is, I'm surprised more things
haven't been fixed (suspend mode isn't working either, which apparently
requires some heavy kernel patches from TI that don't work on recent
Linux versions).
If you're not scared of embedded programming (which means getting
intimate with things like board initialization and linker scripts),
I REALLY recommend something bare-metal ARM like the multitude of
cheap eval boards from ST and Atmel. Or, really, even AVR eval boards
without the Arduino stack taking up room (though AVR GCC isn't really
that nice to work with, and the programming tools don't have great
open source support).
- Dave
...
I intend to bring out the Raspberry Pi shortly. The only downside is that
the USB functionality is hindered greatly by the fact that both USB ports
and the Ethernet port all tie into the same bus. Also, I don't mind running
headless, but with both USB ports taken up by USB-serial converters, I
won't have a spot for a flash drive. Either I'll map a network drive or
just suffer with using the SD card. Then again, if I use a real man's
terminal, I'll save a USB port! :)
You might check out the BeagleBone Black. It?s similar but the hardware is open (fully
documented in 4500 or so pages). I forgot just what the USB config looks like, but I do
remember that the stock board has a pair of USB ports plus Ethernet plus microSD, all
available at the same time. Oh yes, plus on-board flash so you don?t usually need the SD.
And several UARTs. There?s an off the shelf plugin board to provide RS232 level serial
I/O from any one of those UARTs. I did a 4 port RS232 level converter; design files
available if anyone wants them. 
8 Feb
8 Feb
3:39 a.m.
Am 06.02.14 21:44, schrieb David Riley:
The BBB is a nice device, but its bundled software is
terrible enough
to turn me off of using the thing
That is why I put Debian on my BBB as soon as I
got it. Downloaded an
image to a SD card, insert in BBB, boot it up from SD card, copy SD card
to internal flash, done. (IIRC there was a litle script included that
did all the dirty work of partitioning, instaling uboot, ...)
--
tsch??,
Jochen
6 Feb
6 Feb
11:09 p.m.
On 2/6/2014 9:24 AM, Kyle Owen wrote:
On Thu, Feb 6, 2014 at 7:19 AM, Philipp Hachtmann
<hachti at hachti.de> wrote:
A Windows command line version can be had by distributing the Cygwin executable
and the
necessary Cygwin DLLs located in the same directory. Then you can run it from a
regular
windows command window as a command line application. No need to install Cygwin.
That being said, Cygwin is so easy to install, and so useful, that I don't see
why anyone in
this group would ~not~ have it on their windows box.
BTW I have a couple of PDP-8m systems with only floppy (and extra serial cards!)
so I
am ready for beta testing any time ...
Don
I see that you use Windows on the server side - I
don't have Windows :-(
Does it run under Linux as well? Or is the core functionality encapsuled
platform independent? Or do I have to make a Linux version?
I wrote this with
Linux in mind, in fact. I wrote this entirely in C, and
it compiles under gcc for both Mac OS X and Cygwin. I don't have a native
DOS/Windows version, and I don't intend to support one at this time.
So rest assured, everyone: it will is supported on Linux, Mac OS X and
Windows under Cygwin.
11:50 p.m.
linux guys u prolly get it to run under wine
On Thu, Feb 6, 2014 at 10:09 PM, Don North <ak6dn at mindspring.com> wrote:
On 2/6/2014 9:24 AM, Kyle Owen wrote:
On Thu, Feb 6, 2014 at 7:19 AM, Philipp Hachtmann
<hachti at hachti.de>
wrote:
A Windows command line version can be had by distributing the Cygwin
executable and the
necessary Cygwin DLLs located in the same directory. Then you can run it
from a regular
windows command window as a command line application. No need to install
Cygwin.
That being said, Cygwin is so easy to install, and so useful, that I don't
see why anyone in
this group would ~not~ have it on their windows box.
BTW I have a couple of PDP-8m systems with only floppy (and extra serial
cards!) so I
am ready for beta testing any time ...
Don
I see that you use Windows on the server side - I
don't have Windows :-(
Does it run under Linux as well? Or is the core functionality encapsuled
platform independent? Or do I have to make a Linux version?
I wrote this with Linux in mind, in fact. I wrote this entirely in C, and
it compiles under gcc for both Mac OS X and Cygwin. I don't have a native
DOS/Windows version, and I don't intend to support one at this time.
So rest assured, everyone: it will is supported on Linux, Mac OS X and
Windows under Cygwin.
7 Feb
7 Feb
2:59 a.m.
On 2/6/2014 8:50 PM, Adrian Stoness wrote:
linux guys u prolly get it to run under wine
There is absolutely no point in using wine. On linux, just compile it and run,
like any other simple unix program.
On Thu, Feb 6, 2014 at 10:09 PM, Don North <ak6dn at mindspring.com> wrote:
> On 2/6/2014 9:24 AM, Kyle Owen wrote:
>
>> On Thu, Feb 6, 2014 at 7:19 AM, Philipp Hachtmann <hachti at hachti.de>
>> wrote:
>>
>>> I see that you use Windows on the server side - I don't have Windows :-(
>>> Does it run under Linux as well? Or is the core functionality encapsuled
>>> platform independent? Or do I have to make a Linux version?
>>>
>> I wrote this with Linux in mind, in fact. I wrote this entirely in C, and
>> it compiles under gcc for both Mac OS X and Cygwin. I don't have a native
>> DOS/Windows version, and I don't intend to support one at this time.
>>
>> So rest assured, everyone: it will is supported on Linux, Mac OS X and
>> Windows under Cygwin.
>>
>>
> A Windows command line version can be had by distributing the Cygwin
> executable and the
> necessary Cygwin DLLs located in the same directory. Then you can run it
> from a regular
> windows command window as a command line application. No need to install
> Cygwin.
>
> That being said, Cygwin is so easy to install, and so useful, that I don't
> see why anyone in
> this group would ~not~ have it on their windows box.
>
> BTW I have a couple of PDP-8m systems with only floppy (and extra serial
> cards!) so I
> am ready for beta testing any time ...
>
> Don
>
>
6 Feb
6 Feb
4:04 p.m.
And be sure: If you release your software, I'll
try it out.
I see that you use Windows on the server side - I don't have Windows :-(
Does it run under Linux as well? Or is the core functionality encapsuled
platform independent? Or do I have to make a Linux version?
I was wondering if it would be possible to run the 'server' software on
an Rpi. It has a serial port (which can be trivially buffered to RS232
levels), it can, of course, use USB mass storage devices
-tony
8:15 p.m.
On 2014-02-06 08:19, Philipp Hachtmann wrote:
Am 06.02.2014 01:46, schrieb Lyle Bickley:
Incidentally, do you have any plans to ever release your RTL?
-Alan
Great! This ought to work with Philipp
Hachtmann's "Omni-USB" board
for
really fast I/O. When you release the driver, I'll check out it's
performance - RK05 vs. Serial/USB.
I waited for this comment, hehe :-)
And be sure: If you release your software, I'll try it out. 
8 Feb
8 Feb
12:24 p.m.
On Feb 7, 2014, at 00:48 , Philipp Hachtmann <hachti at hachti.de> wrote:
Am 07.02.2014 02:15, schrieb Alan Hightower:
I am not yet familiar with the OmniUSB, but the name sounds intriguing. Can you point me
towards information about what it is and what it does?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
Incidentally, do you have any plans to ever
release your RTL?
Oh, you mean the RTL of OmniUSB? Yes, I could do that now. I will try not to forget that.
1:08 p.m.
On Sat, Feb 8, 2014 at 11:24 AM, Mark J. Blair <nf6x at nf6x.net> wrote:
On Feb 7, 2014, at 00:48 , Philipp Hachtmann <hachti at hachti.de> wrote:
http://pdp8.hachti.de/projects/omni_usb/
It's a new serial interface board that allows for much higher transfer
rates. And it's USB, not RS-232!
In other news...
- I have modified the server to support the standard dumprest RK05 image
(3,325,952 bytes long)
- I have modified the system handler to support a full RK05 image (by
utilizing a second entry point)
- I have modified the server to handle this second entry point correctly
- I have written a non-system handler version, supporting two full RK05
images (with 4 entry points)
- I have successfully compiled an earlier version on a Raspberry Pi...it
runs great! minicom is my terminal emulator of choice, and I'm running the
RPi headless via ssh. Funny...it's actually 300 ms faster at loading BASIC
on the RPi!
- I have modified the system handler to write faster, but I know I've hit
the limit with 19200 baud. I don't think I'll be modifying my board for
anything faster right now, so perhaps those more adventurous than I (or
those with an Omni-USB) can test it out
- I have poorly written a converter utility that converts between Bernhard
Baehr's simulator format, my old format (which looks a lot like RIM/BIN
files, making modification easy), and the dumprest format. This also
includes a way to replace just the bootloader and system handler on the
disk pack. The program is ugly, it runs really slow, and needs major
improvement.
I need to finish modifying the server to support the second RK05 disk pack,
and do a whole lot of testing. I also hope to modify BOOT to allow one to
bootstrap the system the easy way, once OS/8 is booting. This would allow
you to boot from another disk image without having to go through the
trouble of toggling in the RIM loader again.
Also, I'll see about going back in my code and eliminated my BSW and other
non-compliant instructions. I may not have enough room to do so, but I'll
see what I can do.
Today I'll be finishing up the improvements to the server and handlers,
writing some documentation, and most importantly, testing!
Kyle
Am 07.02.2014 02:15, schrieb Alan Hightower:
not to
forget that.
I am not yet familiar with the OmniUSB, but the name sounds intriguing.
Can you point me towards information about what it is and what it does?
Incidentally, do you have any plans to ever
release your RTL?
Oh, you mean the RTL of OmniUSB? Yes, I could do that now. I will try
1:25 p.m.
On Feb 8, 2014, at 10:08 , Kyle Owen <kylevowen at gmail.com> wrote:
Oooh, very nice!
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
I am not yet
familiar with the OmniUSB, but the name sounds intriguing.
Can you point me towards information about what it is and what it does?
http://pdp8.hachti.de/projects/omni_usb/
It's a new serial interface board that allows for much higher transfer
rates. And it's USB, not RS-232! 
6:40 p.m.
New subject: Omni-USB design and source files online
On 08.02.2014 18:24, Mark J. Blair wrote:
It's a board I designed last year. I sell it in my web shop, still some left.
It is a board that plugs into a pdp8/e/m/f/a and plays KL8E. On the other side
you connect it to a computer via USB - and it plays USB to serial adaptor. You
can freely select the device codes with nearly self-explaining DIP switches on
the board. That's *ALL* you need to operate the thing.
Transfer speed is faster than the pdp8 can go.
I just extended the web page pdp8.hachti.de/projects/omni_usb to include the
design files and CPLD source code:
http://pdp8.hachti.de/projects/omni_usb/omni-usb_1.00.tar.gz
Feel free to browse the stuff. You will probably surprised how simple it is.
Kind regards
Philipp
Oh, you mean
the RTL of OmniUSB? Yes, I could do that now. I will try not to forget that.
I am not yet familiar with the OmniUSB, but the name sounds intriguing. Can you point me
towards information about what it is and what it does? 
12 Feb
12 Feb
5:52 a.m.
New subject: Omni-USB design and source files online
On Sun, Feb 09, 2014 at 12:40:18AM +0100, Philipp Hachtmann wrote:
It's a board I designed last year. I sell it in my web shop, still some left.
I'm not very familiar with CPLDs or how powerful they are, but could the
OmniUSB be reconfigured to do other thing. Say implement a VC8E?
I realize the analog signal from VC8E would have to exit the board
somewhere, are there headers that could be used?
Otherwise a more general purpose OmniBUS device might be your next
project?
Cheers,
Pontus.
6 Feb
6 Feb
4:41 a.m.
Hi, congratulations, that looks realy nice, Im luckey enough to have some
real mass storage but still looking forward to trying it out, rerpaired an
M 8655 to be ready :)
I think the guys over in the Vintage Computer DEC Forum would be well
interested in this, could you do a post there ? or I can if you would like.
Dave H
----- Original Message -----
From: "Kyle Owen" <kylevowen at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Wednesday, February 05, 2014 7:16 AM
Subject: Booting OS/8 on a PDP-8/E from a PC
Greetings,
I've been hard at work on an OS/8 system handler that negotiates block
transfers between a PC running a special disk server. The two are
currently
working great! I was able to use the BUILD utility to make my own OS/8 V3D
disk and boot from it. I then thought that it may be possible to take an
existing RK05 image and replace the bootloader and system handler with my
own. Sure enough, it works!
Check it out: https://www.youtube.com/watch?v=YkqVJ6ShV5A
I'll be releasing the source code for all of this within the next few
weeks
as I make minor changes (and mostly tidy it up).
A few details: the handler resides in one page and talks to the server to
negotiate the transferring of pages. To keep the handler small, I'm
offloading as much stuff onto the PC as possible. There's no error
detecting (although this hasn't been an issue for the millions of bits
I've
sent thus far) and the features of the handler are pretty basic. The disk
server is written entirely in C and has been successfully compiled on Mac
OS X and Windows under Cygwin.
The handler sends serial data to an M8650YA (currently addressed at 40/41,
the aux TTY addresses) operating at 19200 baud. This is pretty slow still,
as you can see from the video. But it's usable! And it's bound to get
better with a few more improvements.
To bootstrap the system, the RIM loader is toggled in as the primary
bootloader, and a secondary bootloader is sent in RIM format. Start the
system at 0020 after that, and it'll boot right up.
In summary, anyone with a spare M8650, M8655, or other serial card can now
boot OS/8, even if you don't have an RK05, DECtape, RX01/02, etc.! If you
have a parallel I/O card, another handler could be made for even faster
transfers, I imagine. This would require some extra hardware, though.
Let me know if you have any questions. Again, I'll see about distributing
the source in a couple of weeks, or as I have time.
Kyle
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2247 / Virus Database: 3684/6565 - Release Date: 02/05/14
3821
days inactive
3828
days old
27 comments
15 participants
participants (15)
-
ak6dn＠mindspring.com -
alan＠alanlee.org -
ard＠p850ug1.demon.co.uk -
david＠hheng.plus.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
hachti＠hachti.de -
jkunz＠unixag-kl.fh-kl.de -
kylevowen＠gmail.com -
lbickley＠bickleywest.com -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
philipp＠hachtmann.com -
pontus＠Update.UU.SE -
tdk.knight＠gmail.com