http://classiccmp.org/pipermail/cctalk/2010-January/282022.html
It always suprised me that hre BBC micro used the 6502 rather than the
6809. By the time the Beeb was designed, Acorn had made a 6809 processor
board for their System machines, so they must have had experience with
the chip. THe Beeb is nice, but a Beeb with a 6809 processor would have
been something else :-)
-tony
Hi! When I designed the N8VEM 6809 host processor it is loosely based on an
article I read for the BBC computer called "Dragon in the tube". I am not
very familiar with the UK microcomputers but apparently 6809 "coprocessors"
were fairly common peripherals on their Z80 and 6502 designs. I used a
similar concept for the N8VEM to allow its Z80 SBC to access the 6809 as a
"host processor" peripheral on the ECB.
One of the builders was able to get CUBIX running on the N8VEM 6809 host
processor using the Z80 as its "IO processor". However, I can see how the
implementation can get confusing because it is either a Z80 based system
with a 6809 coprocessor or a 6809 based system with a Z80 IO processor. In
reality it doesn't really matter but it's a matter of perspective.
The N8VEM 6809 CUBIX implementation allows the use of ECB peripherals like
IDE, video, floppy, serial, parallel, etc but it requires the Z80 to serve
all the IO based on 6809 commands. I added the 6809 IO mezzanine board
(power, ACIA, PTM, 2 VIAs, expansion bus) to give builders the option of
using the 6809 host processor as a stand alone computer or to add separate
IO to the N8VEM system when connected to the bus. The idea being to let the
6809 host processor interact with the outside world using its own IO and
only involve the Z80 when absolutely necessary.
The hardware seems to work OK but we'll see where the software goes. I
think with CUBIX the 6809 N8VEM system becomes a lot more practical. The IO
mezzanine fits on top of the 6809 host processor. You can see some photos
here. These are out of date but give a good idea. Recently I fitted an
improved serial cable and the nylon standoff hardware. Also the PTM seems
to be working and that's good.
http://n8vem-sbc.pbworks.com/browse/#view=ViewFolder¶m=m6809
I have many 6809 host processor and IO mezzanine PCBs so if anyone is
interested please let me know. This would be a great opportunity for anyone
who would like to do some 6809 hardware and software hacking.
I think the N8VEM 6809 host processor is the only system I am aware of other
than Dave's homebrew that is running CUBIX. There maybe some other homebrew
systems out there too I can't find them after some searching.
Thanks and have nice day!
Andrew Lynch
Hi guys,
I'm trying to get my hands on a 5.25in double-sided 40 tracks per side
"360K" floppy drive with the Shugart or IBM PC 34-pin connector (either
edge connector or pin header is fine). Does anyone have a spare they'd
like to part with? Slight preference for Teac or Mitsubishi, but
anything will do at this point.
I've checked Ebay, there are tons in the US (complete with "seller does
not ship internationally, don't even ask"), but the only ones I've seen
>from UK sellers are parts scalpers wanting stupid money for them (?149
"sold untested with no guarantee"? really?).
A BBC Micro 40-track drive would also be fine -- as long as it's native
40-track, not 40/80 track switchable or double-stepping (an 80-track
drive mated to a PCB which double-steps the head). Cumana, Viglen and a
few other companies made these, they were extremely common a few years ago.
I'm on the verge of getting DiscFerret write support working (at least
for UNIX PC disks) but the sodding thing won't read anything my 80-track
drives have written!
I'd rather not borrow the 3B1's drive - the DiscFerret is experimental
and a benchtop lashup is hardly an ideal scenario.
Thanks,
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
>
>Subject: VT-180 (Robin) EPROM images?
> From: "Robert Armstrong" <bob at jfcl.com>
> Date: Sat, 10 Mar 2007 20:23:04 -0800
> To: <cctech at classiccmp.org>
>
> Does anybody have images of the v2.1 Z-80 firmware for the VT-180 (aka
>Robin) ? At least, I think 2.1 was the last version ever released. They
>should be DEC part numbers 23-017E3-00 and 23-021E3-00.
>
>Thanks,
>Bob Armstrong
I have enough of them laying around I could supply the actual roms. I've
never imaged them as It's easier to replace the code outright.
Curious why are you looking for them?
Allison
>> >> [...non-ancient disk on Unibus machines...]
>>
> > I'm surely not the only collector who would be willing to pony up
> > some $$$ for such a project....
>
I would certainly pony up some $.
I built my own IDE->S-100 interface (with guidance from my amazing friend, Allison P); it was very easy, hardware-wise.
What makes IDE to Qbus or Unibus interfacing so difficult? There must be reasons, otherwise it would have been done by now.
JS
Hello, folks!
Hope you all had a very merry Christmas, happy Hanukkah, or whatever you
celebrated! Also, best wishes for the New Year, which will be... in
around two and a quarter hours in my neck of the woods :)
It's been a while since I posted anything related to DiscFerret. Rest
assured, I have not been resting on my laurels (Balrog and Lord
Nightmare have made certain of that!). In fact, I've just released a
shiny new toy for all you DiscFerret owners... Well, two actually!
Microcode Release 0026 and C-API 1.3!
New in these releases...:
- Microcode:
- Added a clock divider to the Data Acquisition core. Now you can
specify how much timing resolution you need -- 80ns (12.5MHz), 40ns
(25MHz), 20ns (50MHz) or the full 10ns (100MHz). When set to 40ns, the
DiscFerret matches the Kryoflux for read speed (84 tracks double-sided
in one minute and 45 seconds). At full resolution, it still only takes
three minutes and 25 seconds to image the same disc.
- Completely rewrote the data sync-word detector. All the ripple
clocks and clock-domain crossings are gone, and the data separator is
FAR more reliable. The capture and lock range is about 20% of the
nominal data rate (!), which is more than adequate for most disc drives.
The sync word may be up to 16 bits long, and can also include "don't
care" bits!
- Miscellaneous fixes to the data separator configuration (it was
set for a 16MHz clock, but provided with a 20MHz clock. Despite this, it
still worked fine!)
- C/C++ API
- Support added for the new clock divider register.
Files are all downloadable from the usual place --
http://www.discferret.com/
(or more specifically:)
http://www.discferret.com/wiki/DiscFerret:Downloads
And you can, as always, browse the source code here --
http://hg.discferret.com/
On the cards for the New Year --
- Work has started on a new, simplified API. This will make its grand
d?but some time in the new year.
- I'm working on improving the accuracy of the INDEX pulse storage
logic. When finished, this will improve the accuracy of INDEX timing
measurements to match the data timing measurements! (This is a minimum
of a factor of 8 improvement over the KryoFlux analyser, and a factor of
128 improvement over the current microcode release!)
Special thanks for this release are due to:
Rich Thomson,
Karsten Scheibler,
Sarayan,
Balrog,
Lord_Nightmare,
... and anyone else I've forgotten!
Thanks!
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
Hi folks,
I have a lot of 5 Digital LK401 keyboards. I am asking $20 each plus
shipping from 91942 (San Diego). Contact me off the list if you're
interested. Thanks!
-Kurt
I have powered up the LA36 with the Selenar Graphics board in it, and
>from the information kindly obtained by list members (Byte Magazine
article about the Selenar Graphics II), I have been able to verify that
the unit indeed works. The graphics mode works, and all of the other
features documented in the Byte article seem to function properly.
The issue that I've found is that only 5 of the 7 print pins are
working. Numbered with the top pin as number 1, it is the 3rd and 6th
pins that are either not firing at all, or are jammed such that they
can't come forward enough to make an impression.
I can't find a service manual for this unit online anywhere, so I'm
wondering what the best approach to diagnosis would be. I do have
schematics, but since the unit has a Selenar Graphics II logic board,
I'm not sure how well the schematics will help. Since the Selenar board
replaces the stock logic board, I can safely assume that it retains the
pinouts for the connectors that go from it to the power board that has
the drivers for the solenoids in the printhead. So, I can probably
scope out the drivers to see if they are firing on pin 3 and 6 when
printing characters that require those dots, which I will do when I have
time, but I'm wondering the next step would be if I find that there are
firing pulses coming out of the pin drivers for pin 3 and pin 6.
Obviously, if I find that the pulses aren't being generated, then I have
to dig into the solenoid drivers for these pins and figure out what has
failed and fix it.
If I find that the solenoid drivers are OK, then what should be done
next?
Would it be to remove the printhead and do what Tony suggested, which
would be to use a bench power supply (I have a good Tektronix bench
supply does truly does deliver 0.00V) to try to fire the solenoids to
see if they are gummed up? If so, how do I go about removing the
printhead to do this? Just from looking at things, it looks like I would
have to do a lot of disassembly to get the printhead out of there. Does
the printhead come off separately from the carriage that it rides on, or
do I have to remove the whole carriage assembly?
Any guidance would be most appreciated.
Thanks,
Rick Bensene
One of these nifty Esprit 350C terminals Cindy was noting a week or so
ago has arrived, but I can't find a manual online anywhere. I have
figured out how to get to the config screen, but can't figure out how to
get the terminal to try to connect to an ip address.
Anyone have a manual or know how to do that?
Jim
--
Jim Brain
brain at jbrain.comwww.jbrain.com
Hi folks,
I'm currently sorting parts of my stuff. And I found out that I have less RK05
packs with 16 sectors (PDP8) than drives. I have some 12 slot packs as well.
But I could need more 16 sector packs.
I have access to some masses of 12 sector packs... Probably I'm not alone with
that situation.
If there's enough interest it could be possible to machine new center hubs for
the packs. With custom sectoring. I'm quite sure that the biggest part of the
cost would be the programming and setup of the CNC that turns the hubs. Then
changing the sectoring to customer demands will probably cheap and easy. So the
idea of making new center hubs could be quite interesting for the folks who need
the same pack style for other computers with other sectoring. I know of IBM 1130
and some HP computers using the same packs which were originally an IBM idea.
Any comments? Interested? Your feedback helps me to decide if it's reasonable to
do it or better put the idea into the trash.
An important point would be the amount of cash one is willing to pay for
one center hub.
Kind regards
Philipp
--
Hi,
I am in the process of working on a new Amiga game, but I have the
graphics saved in .PNG format. I could convert them to the much
easier to decompress .IFF format, but .PNG image save many more
bytes (e.g image is 15KB saved as an .IFF vs. 9KB as a .PNG).
I have sucessfully decoded all the easy stuff, but am currently trying
to decode the IDAT chunk (where the image data is stored).
The format of the data is defined as follows (straight out of the RFC1951
Deflate Compression document available online):
??? 5 Bits: HLIT, # of Literal/Length codes - 257 (257 - 286)
??? 5 Bits: HDIST, # of Distance codes - 1 (1 - 32)
??? 4 Bits: HCLEN, # of Code Length codes - 4 (4 - 19)
??? (HCLEN + 4) x 3 bits: code lengths for the code length
??? alphabet given just above, in the order: 16, 17, 18,
??? 0, 8, 7, 9, 6, 10, 5, 11, 4, 12, 3, 13, 2, 14, 1, 15
??? These code lengths are interpreted as 3-bit integers
??? (0-7); as above, a code length of 0 means the
??? corresponding symbol (literal/length or distance code
??? length) is not used.
??? HLIT + 257 code lengths for the literal/length alphabet,
??? encoded using the code length Huffman code
??? HDIST + 1 code lengths for the distance alphabet,
??? encoded using the code length Huffman code
??? The actual compressed data of the block,
??? encoded using the literal/length and distance Huffman
??? codes
??? The literal/length symbol 256 (end of data),
??? encoded using the literal/length Huffman code.
All the documents I found online either say use the zlib library or point to
the RFC1951 document :(
Does anyone know how to decode the literal / length (HLIT) and distance
codes (HDIST)?
Huffman compression was always something I found hard, but it seemed
much easier after finding this page online:
http://www.cs.duke.edu/csed/poop/huff/info/
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
