Henk,
Love the "Blinkenlight project". ;)
Do tell us more, if you have a web page please point!
Allison
>
>Subject: RE: CUBIX/6809 updates
> From: "Gooijen, Henk" <henk.gooijen at oce.com>
> Date: Sun, 11 Dec 2005 22:48:15 +0100
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Great Dave.
>I will soon be picking up the intended floppy disk interface for my 6809 board (Blinkenlight project).
>I must definately have a better look at your pages! Your site was already known to me :-)
>Perhaps I should not put so much work in my 6809 code, but grab yours. But then I'll ask first!
>
> greetz,
>- Henk, PA8PDP
>
>________________________________
>
>Van: cctalk-bounces at classiccmp.org namens Dave Dunfield
>Verzonden: zo 11-12-2005 12:55
>Aan: cctalk at classiccmp.org
>Onderwerp: CUBIX/6809 updates
>
>
>
>For the benefit of any one who is building up a 6809 based system and
>planning to run my CUBIX OS (or thinking about it):
>
>I have just updated the source code, documents, disk images and simulator for
>the CUBIX/6809 system which are available on my site.
>
>Main change is that I have ported my Micro-C 6809 compiler over to run native on
>the system. Languages currently included with CUBIX are: Assembler, Asp (high-
>level assembler), Basic, Forth, APL and now C.
>
>Due to the large size of the C documentation, the documentation diskette has
>been split into two physical disks (well... images for the simulator), "System/Utilities"
>and "Languages".
>
>The C compiler happened to expose an obscure stack corruption bug in the OS,
>so I have hunted that down and swatted it.
>
>I've also updated the simulator to include the ability to import/export text files as
>console input/output, and enhanced the debugger to include the ability to
>disassemble in either "6809" mode ("SWI" == "SWI"), or in "CUBIX" mode
>("SWI / FCB xx" becomes "SSR xx") and a nifty "Step over" command which
>allows you to execute at full speed until the stack pointer returns to where you
>started. (The debug enhancements are brought to you courtesy of the stack
>corruption bug :-).
>
>Regards,
>Dave
>
>--
>dave04a (at) Dave Dunfield
>dunfield (dot) Firmware development services & tools: www.dunfield.com
>com Collector of vintage computing equipment:
> http://www.parse.com/~ddunfield/museum/index.html
>
>
>
>
>
>
>This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
>If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
>If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message.
>Thank you for your cooperation.
Speaking of audio cassette storage, I received this inquiry
to my web. Click the link to hear the data he has... What's
odd to my ear is that the data seems to be packeted between
carrier. Might this be someone's custom data, as opposed to
ordinary program load/save?
As for why MP3s work fine and .WAV is unnecessary, MP3's
compression divides the signal into ~32 frequency bands, then
encodes the amplitude of those over time. The typical
two-frequency sine modulation used by cassette data recorders
probably fits quite well into those two bins, and MP3 would
recreate the simple sine waves quite well.
After all, some of the hardware/software decoders within the
classic PCs (as well as their emulators) may have only used
the timings of zero-crossings, so they aren't very sensitive
to perfect reproduction of the waves.
- John
>Date: Sat, 10 Dec 2005 16:11:34 +0100
>From: Paul Geisler <paul.geisler at web.de>
>To: jfoust at threedee.com
>Subject: unknown data tape
>
>
>hello.
>
>i found some old tapes i know nothing about ecept by title it may contain interesting information, and came from merely professional use.
>
>the tapes are recorded on standard compact casette but with some dedication to data recording for example switchable write protection etc.
>the label reads "T 300 Certified Data Casette".
>
>i capture the contents by stereo tape recorder, found both channels nearly equal so guess this mono, mixed them. the tapes are two-sided like normal audio ones.
>
>a strange thing is, that the recording is in small "packets", with empty tape inbetween. i first guessed it is only "empty formatted" tape, but the data packets seem to contain a varying length of information. still strange to waste more than a half of material this way? also strange the packets are ending with a simple tone, instead are headed with, so maybe this is used backward at original drives.
>
>here is a seven packet sample some minutes after beginning of one tape; all tapes seemed to have this same "format" from start to some end location which is not the real tape end:
>http://hirnsohle.de/test/datenSnipplet.wav (16bit mono microsoft-wav 624kb)
>
>i would be very happy if you had any idea how to look at the contents (if any).. i'm currently searching for some sofware "tape modem". i know such things for C64 datasette tapes, so maybe you know some universal program, where different emulations or flexible parameters can be used to find a matching demodulation/decoding?
>
>thanks very much & best regards
>Paul Geisler
Great Dave.
I will soon be picking up the intended floppy disk interface for my 6809 board (Blinkenlight project).
I must definately have a better look at your pages! Your site was already known to me :-)
Perhaps I should not put so much work in my 6809 code, but grab yours. But then I'll ask first!
greetz,
- Henk, PA8PDP
________________________________
Van: cctalk-bounces at classiccmp.org namens Dave Dunfield
Verzonden: zo 11-12-2005 12:55
Aan: cctalk at classiccmp.org
Onderwerp: CUBIX/6809 updates
For the benefit of any one who is building up a 6809 based system and
planning to run my CUBIX OS (or thinking about it):
I have just updated the source code, documents, disk images and simulator for
the CUBIX/6809 system which are available on my site.
Main change is that I have ported my Micro-C 6809 compiler over to run native on
the system. Languages currently included with CUBIX are: Assembler, Asp (high-
level assembler), Basic, Forth, APL and now C.
Due to the large size of the C documentation, the documentation diskette has
been split into two physical disks (well... images for the simulator), "System/Utilities"
and "Languages".
The C compiler happened to expose an obscure stack corruption bug in the OS,
so I have hunted that down and swatted it.
I've also updated the simulator to include the ability to import/export text files as
console input/output, and enhanced the debugger to include the ability to
disassemble in either "6809" mode ("SWI" == "SWI"), or in "CUBIX" mode
("SWI / FCB xx" becomes "SSR xx") and a nifty "Step over" command which
allows you to execute at full speed until the stack pointer returns to where you
started. (The debug enhancements are brought to you courtesy of the stack
corruption bug :-).
Regards,
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
This message and attachment(s) are intended solely for the use of the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law.
If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify the sender immediately by telephone and with a "reply" message.
Thank you for your cooperation.
>
>Subject: Re: CUBIX/6809 updates
> From: Tom Uban <uban at ubanproductions.com>
> Date: Sun, 11 Dec 2005 10:37:55 -0600
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Cool Dave!
>
>Is this running on other hardware than your homebuilt 6809 machines? Can
>you please describe the Cubix features (disk?, commands?, etc.)? Or should
>I just RTFM...
I'll comment. Ave has two distinct systems listed on his web site and their
interesting.
I'm working on building one for portable(toteable) use. First I'd say I'm
>from the 8080/8085/z80/z180 mostly world though I've played with lots of
others. This is however my first real venture into the 68xx world though
I'd looked at 6809 for a long time and have a COCO3 to play with. So I'm
not near as comfortable with 6809 as many may be. What I've learned
looking and working with the sim is that it's a very good cpu and somehow
never got the populartity I'd have expected for the performance.
Basic features:
6809 with a low chip count and despite the apparent low clock speed the
CPU cycle usage is different (close to 6502) and operating speed is
decently fast.
Basic design (portable) is 48k ram and ROM resisdent OS.
The resident OS can address up to 32mb of storage per logical device
and the OS is sophisticated in that sparse files and scatter/gather
are nominally part of it (like CP/M, unix, VMS). The OS is easily
configured for any device (floppy, IDE, CF whatever). Same for
IO (serial memory mapped video).
One central item in my mind is that it's complete with supporting
software such as editors, assemblers, languages and the sources are
there. The documentation is good as well. Reading the manual gives
depth to what I'm only outlining here.
The outstanding feature if your interested at all, there's a good
simulator for the hardware with matching software to play with,
test drive if you will. The sim plays well on my P166 NT box,
my W98 P100 and a dosbox.
>I wrote a ton of 6809 assembly when I was programming pinball machines
>at Williams/Bally in the 90's.
;) Then I'd expect you'll find programming the '09 familiar.
Allison
>--tnx
>--tom
>
>At 11:55 AM 12/11/2005 +0000, you wrote:
>
>>For the benefit of any one who is building up a 6809 based system and
>>planning to run my CUBIX OS (or thinking about it):
>>
>>I have just updated the source code, documents, disk images and simulator for
>>the CUBIX/6809 system which are available on my site.
>>
>>Main change is that I have ported my Micro-C 6809 compiler over to run
>>native on
>>the system. Languages currently included with CUBIX are: Assembler, Asp (high-
>>level assembler), Basic, Forth, APL and now C.
>>
>>Due to the large size of the C documentation, the documentation diskette has
>>been split into two physical disks (well... images for the simulator),
>>"System/Utilities"
>>and "Languages".
>>
>>The C compiler happened to expose an obscure stack corruption bug in the OS,
>>so I have hunted that down and swatted it.
>>
>>I've also updated the simulator to include the ability to import/export
>>text files as
>>console input/output, and enhanced the debugger to include the ability to
>>disassemble in either "6809" mode ("SWI" == "SWI"), or in "CUBIX" mode
>>("SWI / FCB xx" becomes "SSR xx") and a nifty "Step over" command which
>>allows you to execute at full speed until the stack pointer returns to
>>where you
>>started. (The debug enhancements are brought to you courtesy of the stack
>>corruption bug :-).
>>
>>Regards,
>>Dave
>>
>>--
>>dave04a (at) Dave Dunfield
>>dunfield (dot) Firmware development services & tools: www.dunfield.com
>>com Collector of vintage computing equipment:
>> http://www.parse.com/~ddunfield/museum/index.html
I'm interested in setting up a network of hobbyist DEC machines linked
together in a DECnet phase IV network. Why? I suppose there's no really
good reason, but it seems like it would be fun to be able to do "SHOW NET"
or "NCP SHOW ACTIVE NODES" and see a whole long list of machines that aren't
mine :-) Besides, it would be a good way to share access to real,
non-simulated, VMS/RSX/RSTS and even, maybe, TOPS-10 or 20, machines.
Does anyone else agree? Is anyone else interested in participating?
I know I'm not the first to think of this; in particular, I've had a few
email discussions recently with Johnny Billquist about HECnet,
http://www.update.uu.se/~bqt/hecnet.html
At some point I'd like to link up with HECnet, but right now Johnny is
having ISP problems and it sounds like HECnet is down to one or two nodes.
Are there any other hobbyist DECnet associations that are going strong?
As for technology, it seems like the best thing would be to use the
Internet as our communications medium. Nobody wants to pay for
point-to-point leased lines anymore, after all. Multinet, TCPware, and even
DECNet Phase V all have the ability to send DECnet traffic over IP. Right
now I'm leaning towards Multinet - they have a free hobbyist license
program, and Multinet can create point-to-point virtual DECnet circuits
using UDP packets that can be routed over the Internet. They're simple to
set up and administer.
I have a fair amount of Internet bandwidth available at my location, and I
can set aside a VS4000 VLC or model 90 to serve as a dedicated Phase IV
routing node.
Bob Armstrong
> Subject: Using an ipod shuffle with 8-bit machines
>
> I found this link yesterday :
>
> http://sbeam.dk/blog/?p=9
>
> I thought some people here might find it interesting, I have
> done similiar things myself with a portable cd-player and
> with a pc sound card. A bit expensive just for this, but if
> you get the quality quite high you can vastly increase the
> loading speed.
I would expect the lossy compression of MP3 would drop precious bits.
>
>Subject: Re: Using an ipod shuffle with 8-bit machines
> From: Pete Turnbull <pete at dunnington.plus.com>
> Date: Sun, 11 Dec 2005 13:52:03 +0000 (GMT)
> To: "General Discussion: On-Topic and Off-Topic Posts"<cctalk at classiccmp.org>
>
>On Dec 11 2005, 13:34, Dan Williams wrote:
>> >
>> > I would expect the lossy compression of MP3 would drop precious
>bits.
>> >
>> >
>> >
>> It says in the article that he used wav files and mp3's didn't work
>
>Hmm.. All I can say is it works for me and some other people who use
>it for Exidy machines, and I know several people who've used MP3s for
>BBC Micros. Perhaps the Amstrad machine is being unusually picky or
>perhaps there was something unusual about the MP3 encoding he tried.
>
Loosing bits shoulld not render a problem. The original audio recorders
were pretty low fidelity so loosing a few waveform buts are trivial.
Keeping mind that cassette port data is binary bits represented as audio
tones. That data had to withstand all the assaults a casette and the
associated 20-50 dollar lo-fi recorder and player delivered.
Lossy MP3 is very hi-fi compared to that.
Allison
On Dec 11 2005, 13:34, Dan Williams wrote:
> >
> > I would expect the lossy compression of MP3 would drop precious
bits.
> >
> >
> >
> It says in the article that he used wav files and mp3's didn't work
Hmm.. All I can say is it works for me and some other people who use
it for Exidy machines, and I know several people who've used MP3s for
BBC Micros. Perhaps the Amstrad machine is being unusually picky or
perhaps there was something unusual about the MP3 encoding he tried.
--
Pete Peter Turnbull
Network Manager
University of York
On Dec 11 2005, 8:22, James Fogg wrote:
> > Subject: Using an ipod shuffle with 8-bit machines
> >
> > I found this link yesterday :
> >
> > http://sbeam.dk/blog/?p=9
> >
> > I thought some people here might find it interesting, I have
> > done similiar things myself with a portable cd-player and
> > with a pc sound card. A bit expensive just for this, but if
> > you get the quality quite high you can vastly increase the
> > loading speed.
>
>
> I would expect the lossy compression of MP3 would drop precious bits.
It doesn't. Some of us have been doing this for years. It's not new
:-)
Almost all the games and commercial software I have for my Exidy
Sorcerer are MP3s which load at 1200 baud.
--
Pete Peter Turnbull
Network Manager
University of York
I found this link yesterday :
http://sbeam.dk/blog/?p=9
I thought some people here might find it interesting, I have done
similiar things myself with a portable cd-player and with a pc sound
card. A bit expensive just for this, but if you get the quality quite
high you can vastly increase the loading speed.
Dan