Copyright: Mark Usher


Contents

This is an archive of the bbc-list@ohm.york.ac.uk from 21.05.1992 until 12.02.93, not very much, but it was all I could find, but there is still some pretty usefull info about the beloved "beeb".  I converted the original text file into a Windows help file to try and make it easier to search for inormation, I hope it helps you too.

If you have any comments or know where there are any more message archives of this list then please email me.

Mark Usher

marku@woergl.netwing.at

Some of the people on the list

Postings


People on the list

The following people are on the mailing list, and have submitted personal interests and equipment lists:

Andrew Alf Leahy

Angus Duggan

Alan Ralph

Alan Meban

Pat Cain

Chris StJohn

Daniel Bowen

Mik Davis

David Alan Gilbert

Gerben 'P' Vos

Ian Stephenson

Jason O'Broin

John Whistler

Kyle Dawkins

Matthew Sweet

M.J.Ebourne

mwiles@Madge.MHS.CompuServe.COM

Robbie Steele

Stephen McGuinness

Thomas J Hughes

Mark J E Bellis

Julian Wright

Richard York


Andrew Alf Leahy

alf@st.nepean.uws.edu.au

BBC Model B series 7, 128K SWRAM, 2x80T FD, Music 500 + 5000/87 s/w, Music 2000 (MIDI) driving a Roland D-110 module, Speech, 9-Pin printer, 24-Pin colour printer, 8-pen colour plotter, Netcomm 24/24 Modem, lot's of s/w (we'll that's my opinion - but most of it's at least 5 yrs old!), Apple MAC mouse converted to run like AMX Mouse (plus AMX Art/Pagemaker), Wico Trackball converted to look like AMX Mouse!, assorted hardware bits (lightpens, joysticks, speech processors, User Port "break-out" type box with flashing LEDs - wow!).  Ex-Software Librarian for OZBEEB the Sydney Acorn Users Group (it still exists - mainly Arc nowadays). I've had my Beeb since mid-1983, main interests are graphics/music. I mostly use it as a terminal for logging onto Uni., and some word-processing (using Interword - which I prefer over View).

I'm a final year student (hopefully) at Uni. Western Sydney, studying part-time Applied Science - Computing, and I work as full-time casual(!) SA for our DEC/Ultrix machines.


Angus Duggan

ajcd@dcs.edinburgh.ac.uk

BBC Model B series 7, 65C02 second processor (Tube), 80K SWRam on modified ATPL board, 2x80 track floppy discs using 8271 controller and my own hierarchical DFS (with advanced Tube support, utilities and Acorn compatibility built in), AMX compatible mouse, Mono monitor, own Assembler/Disassembler, Music 500/5000. Quite a lot of software/ROM Images/etc.  Write most of my own programs in assembler, including a major re-write of Elite (you can buy new ships, take courier missions, ship configurations/speeds/armour/manouvreability are all different, on-line encyclopaedia, 6502 Tube support, replaced cop out features, much harder...).

Don't use it a lot now, but if I can get a Music 4000 keyboard and other expansions at reasonable prices, I'll probably resurrect it.


Alan Ralph

aralph@cix.clink.co.uk

At the moment I've got a Master 128, with a Turbo Co-processor Board, and Morley AA ROMboard inside. Outside there's a Morley Smart Cartridge, a switchable 40/80T disk drive, a Hi-Tec EC2400 modem, a Music 5000, a Morley Hard Disk, and a Star LC-200 printer. Oh, and a monitor currently on it's last legs.

I'd love to have an Archie if I could afford one, but as I'm currently unemployed that's a bit of a problem! So I'm stuck with the Master for now.

Believe it or not, I actually read Usenet OFF-LINE, on my Master, with a little help from the EDIT command of the View word-processor.

I'm co-moderator of the BBC conference on CIX, the Compulink Information eXchange, which is pretty quiet these days. I also read, and occasionally contribute to, the BBC Echo on FidoNet (still going strong, just) via the World of Cryton BBS.


Alan Meban

u9105611@athmail1.causeway.qub.ac.uk

Setup:

BBC Master 128K

Dual switchable 40/80T disk drive

Epson LQ550 24-pin printer

A crummy portable tv

My claim to fame is a selection of on-screen clocks, mostly working from sideways ROM - including a rather nice analogue clock that sits in the top right of the screen.


Pat Cain

cain_p@kosmos.wcc.govt.nz

 I run Sideways BBS (sideways.welly.gen.nz) which is currently running on a cheap PC.  Sideways is (believe it or not) named after sideways ram on the beeb--we must have been desperate for a name back in 1988.  Sideways used to run on my BBC Master under EBBS on 2x640k ADFS discs.  I had wanted to put a hard drive on the Master and run the BBS on that, but my power supply died and then I had many other nasty problems with the machine and it was out of action for around 2 years.  In that time I bought a cheap PC for the BBS to run on.

Now, this BBS here used to have packs of BBC software on it but we ran out of disc space so had to move the software to tornado.welly.gen.nz (neither sideways or tornado are directly connected to internet, so you can't ftp to them, only mail..) I will be getting a bigger hard disc for this PC soon and will move the BBC software back here and write a mailserver so people can request it via e-mail, though I suppose I'll have to kill off all the pirated games to keep out of trouble.

My BBC Master has a 512 board, mono monitor, 32k extra SRAM, and the Music 87/500/5000.


Chris StJohn

stjohn@poly.polytechnique.fr

I've not really got a BBC but rather a Cambridge Workstation. Nevertheless I'm looking around for good BBC software to run as well as trying to port an ANSI C compiler to Panos. Maybe eventually I'll write a better (multi-tasking) OS to replace Panos but for now I'm stuck with it. Anyway, 32k RAM, 32k Shadow, 32k Sideways when I can get 'round to soldering it in. 20Mb HD, 1Mb on the 32016 which will soon be running at 10MHz. Mail me if you've got a 32016 2nd processor as I'm looking for other owners to share information on hacking Pandora.


Daniel Bowen

daniel@yoyo.cc.monash.edu.au

- BBC Model B (Issue 7), mono monitor

- Watford "Solderless" Sideways ROM/RAM board with 16Kb sideways    RAM

- Watford Shadow RAM board (32Kb)

- 80 track disc drive (allegedly double sided, but side 2 won't work..)

- 2400 baud modem

- AMX Mouse

- Watford Video Digitiser

Roms:   (in order of me remembering them)

- Acorn DFS 1.20

- Basic 2

- ISO Pascal

- Beebug C

- View 2.1

- Viewsheet

- Shadow RAM OS

- AMX Pagemaker / Pagemaker Support ROMs

- MegaROM

(Probably one or two others I've forgotten.. hmm.. two at the most!)


Mik Davis

davism@uhura.aston.ac.uk

OK, firstly, I own an issue 7 model-B with 16K s/w RAM and a single switchable drive (5.25 inch)

Having got that out of the way, My interests are networking (a little difficult without an interface) and I do quite a lot of work in a school with respect to this.

My other main interests are Elite and trying to get together enough money to buy an Archimedes. (tho' this may be set back by the recent announcement of a SCSI interface for 35(ish) quid).

In terms of wish lists, I could do with a Hard Drive (couldn't we all) and a decent C compiler that supports floating point and can compile stand-alone code which is not HUGE (as small-C 0.70 does).


David Alan Gilbert

gilbertd@p4.cs.man.ac.uk

1) Series 3 board , BBC micro before they changed it to British Broadcasting Corp.,	which came with 0.1 in ROM and Basic 1, but has since been upgraded and now has, an ATPL board with 16K of non-battery backed ram, a watford shadow ram board, a PMS 64K battery backed ram disc on the 1MHz bus, and Acorn 8271 DNFS (1.20) with dual (full height) 100K drives.

It is used mainly for developing software for a little 6502 controller board I built.  I built an eprom emulator for around #20 which hangs off the user and parallel ports.  At one time a long time ago it had a 6502 second processor. Its 10 years old in September and still works most of the time.

2) Model B series 7 board - also with Acorn 8271 DNFS, and very little else on it.  The drives on it are dual full height 100tpi drives bought second hand (when I didnt know they were 100 tpi).  I really would be interested to know what machines used 100tpi drives.	This was used in business for around 6 years running software off tape and then off the ROM Filing System until it was bought home about a year or two ago. This gets used mainly as a terminal for packet radio (on that note

has anyone managed a really cut down TCP for the beeb?)

3) A master 128+512 board.  A more recent addition to the family, the 512 board is useless and was bought when it was only #99.  It has a pair of 800K drives on it.  This is mainly used for word processing in View now - somewhere around we have an AMX mouse and Pagemaker/Super Art.


Gerben 'P' Vos

gpvos@cs.vu.nl

Now, my equipment... I have an Electron with a Plus 1, a Plus 3 and Rombox.  In the Plus 1 i have 32K Sideways RAM (battery-backed) and a Pace RS423 interface, connected to my modem.

My current project (for more than a year now, progress is a little slow) is a terminal emulator with Ymodem file-transfer and ANSI emulation. Already works quite nice.


Ian Stephenson

ian@ohm.york.ac.uk

I've got an issue 3 model B, 48K s/w Ram + single switchable drive. I've also got an AMX mouse and a Music 500. I've a 6502 2nd processor and a 32016, though Panos is a bitch without ADFS.

A good C compiler would be VERY usefull. I've also just aquired two teletext adaptors, and am planning to put one of these on the net.


Jason O'Broin

J.P.O'Broin@ncl.ac.uk

BBC Model B. Issue 7. OS 1.2

Solidisk 1770/8271 switchable disk controller board

(This allows me to use DFS with the 8271 to be *totally* compatable with everything and ADFS with 1770)

ATPL Rom Board - 16K RAM + host of roms inc. my own Eprom Programmer - if anyone wants any EPROMs blown, I'll be happy to over the summer

Dual 40/80 5.25" floppy


John Whistler

JOHN_W@vulcan.mentec.ie

BBC 'B' Issue 7

Acorn DFS & 2 80-track floppies (one switchable) Torch Z80 2nd Processor

Acorn 6502 2nd Processor

Solidisk 256k board

Watford Sideways ROM board

My interests are programming, educational software & games


Kyle Dawkins

kldawkins@descartes.waterloo.edu

I am supposed to say what hardware I have... right now, I have nothing. Zip. Zero. Bugger all. Not a sausage. Nada.It's all back home in NZ.

In NZ I have a BBC B with 64KSWR, 400K drive, etc. A pretty standard system.

When I used my BBC I did a great deal of work with fonts (and co-wrote a font editor for the BBC B which is far far better than anything available on the market. Right, Pat?) and music (I did tons of music software and entered a great deal of music.


Matthew Sweet

matthew@tadtec.co.uk

I have a BBC B (issue 3 PCB), with a sideways ROM extension board with 16K RAM in the most important slot, but no battery back-up.

I have a Z80 second processor that I have never used, but will probably get around to playing with when I have the disk support.

My interests include both H/W and S/W, but S/W tends to win as it is cheaper to play with than H/W! I am interested in a good "C" cross compiler/assembler/linker for either the 6502 or the Z80 (or both). It could execute on either, and would preferably come with the source. Especially nice would be a linker that had the facility to remove unreferenced functions from linked-in library modules, thus reducing the size of the executable.


M.J.Ebourne

M.J.Ebourne@southampton.ac.uk

I have a Beeb with Solidisk 256k 4MHz board, 8271 & 1770, Music 5000, Star LC10, 6502 2nd proc and a 32016 2nd proc.

I also have a Master with a 6502 2nd proc., and lots of extra hardware such as eprom progger, etc.

The last bit is an A5000, which is why the former stuff is less used these days. Anyhow, I still prog. my Beeb and it is undoubtably the best machine for interfacing.

I see people are interested in the 32016s. Unfortunately I haven't had time to play with mine very much, and also due to the lack of a technical manual I have not done any programming on it. (Also the lack of a compatible ADFS makes matters worse. Anyone got one?)


mwiles@Madge.MHS.CompuServe.COM

mwiles@Madge.MHS.CompuServe.COM

I have an ancient (series 3) BBC B with Watford DFS, 1x40 and 1x40/80 drives, AMX mouse, ATPL sideways board with 16K RAM and full house of (mostly the usual, some home grown) ROMS.

Current interest: making the Mandelbrot set algorithm run as fast as possible.

Current want: a good, fast, cheap 16 or 32bit 2nd processor with reasonable amount of RAM (eg 680xx or 320xx, min 256Kb)


Robbie Steele

rsteele@geog.canterbury.ac.nz

Own: BBC Model B (issue 7)... 64k swr, Speech, 8271 DFS....


Stephen McGuinness

smcgnnss@unix2.tcd.ie

BBC Master 128K

80186 512K Co processor - does an ok job of PC emulation

1 switchable 40/80 track 800K drive

1 80 track 800K drive

A modem - v21/v23 - very old but I got it cheap

A printer

I mainly use the machine for word processing, programming and logging on to my College's Unix  machine.


Thomas J Hughes

thughes@dcs.warwick.ac.uk

As I've just joined this group, I'd better give people an idea of my setup (not that I've got it here anyway). It's a Master 128 with very little added apart from a disc drive and monitor. I also have the Replay system installed with the OS1.2 addition, so I can have a stab at running old model B stuff which don't work on the master. Finally, I have the Macrom macro assembler installed.


Mark J E Bellis

u1mjeb@ohm.york.ac.uk

master 128

double 40/80 5/25" drive

med res colour monitor

dmp2000 dot-matrix printer

my particular areas of interest are:

- disk systems (things like how to protect/crack disks, and write new filing systems)

- robotic control (paticularly of lego models ;-) )


Julian Wright

wright_j@kosmos.wcc.govt.nz

Well I used to use a BBC B with a 1770 DFS and ADFS, and a Solidisc 4 Meg 32k board. Now I have an A5000. But the BBC emulator plays a mean game of Starship Command...


Richard York

yorkr@p4.cs.man.ac.uk

I am the 'famed' producer of the SCSI interface which everyone seems to be interested in :-) As has been mensioned several times by now the price will be about 35 pounds, although I'm not sure how much it would cost to send it abroad.

I am technical advisor for Solinet, the beeb user group, originally set up to support Solidisk (STL) products, but now covering everything that has an Acorn badge on it! I will post the editors name and address when I remember.

My setup consists of;

Issue 7 model B,

STL 32K 4 meg board (runs processor @ 4MHz, with lots of SWR and Shadow),

Replay system (Vine Micros),

Quest mouse + paint (excellent, incase anyone is wondering)

SCSI host card plus 44 Meg SyQuest removable hard drive,

2*80 track doublew sided drives,

STL 1770 DDFS interface.

2 inch fan mounted in the beeb lid :-) (no I'm not kidding)

And of course about 100 ROM images ;-)


Postings

Re: Beeb hard discs and host adaptor cards.

Re: Beeb hard discs and host adaptor cards/Mailing list

My interests etc...

Re: My interests etc...

Re: My interests etc...

My equipment & interests

My equipment

someone mentioned ADFS

My beeb setup and SCSI interface

Re: bit lists - who has what..

Someone on monochrome mentioned a mailing list on bitnet

acorn-l

Re: acorn-l

SCSI

The mailing list (surprisingly)

All the info you wanted but where afraid to ask

Re: All the info you wanted but where afraid to ask

IBM Reader

Introductions

Introductions

A bit about me and my kit.

tcc via !65host on a acorn archimedes ?

New Member

No Subject

DOS reader

SCSI interface board.

BBC Master IBM disc reader query

Comms program

Re: Comms program

Re: Comms program

Re: Comms program

Re: Comms program

Re: Re: Comms program

My set up

What disk drive? (was My set up)

Re: What disk drive? (was My set up)

8271->1770 upgrade

Music 500(0) and other ramblings

Re: Music 500(0) and other ramblings

Re: Music 500/0 +

Hi there

Re: Hi there

Re: Hi there

View

Well...

'Posting' software

Re: 'Posting' software

Re: 'Posting' software

posting software

re: posting software

Re: posting software

Re: posting software

ftp'ing to shiraz??

Re: ftp'ing to shiraz??

beeb SCSI interface card.

Re: beeb SCSI interface card.

No Subject

Re: your mail

Re:

archivers

TequilaComm

BFM

Arc by Bart Bruns (was Re: BFM)

Archivers

Archiver

Re: Archiver

Re: Re: Archiver

Update my info on Shiraz - thanks

ROM Extension boards

Homebrew s/w RAM

User Guides and hardware bits

Archiver

No Subject

Advanced user guide

Re: Advanced user guide

Upgrade your Arc to a Beeb

Archiver (again!)

For Sale ?

ZIP Arc/unarc

BBC Archiver, Tequilacomm, Game

zip & ram

zip

Re: shiraz

SW RAM wiring

Defender

Defender

ram

Manuals

Manuals

Re: Manuals

Re: Manuals

Re: Manuals

ADFS

ADFS

Re: ADFS

Re:  ADFS

Re:  ADFS

Re: ADFS

Re: ADFS

Re: ADFS

ADFS and PAGE

Re: ADFS and PAGE

ADFS and rom memory claim

Re. ADFS

CFV: comp.sys.acorn reorganization

Screen memory

Re: Screen memory

Re: Screen memory

Re: Screen memory

Re: Screen memory

Memory

Memory

SWR

Acorn Atom Found

UnZip

Holiday mailings

Re: Holiday mailings

Re: Holiday mailings

No Subject

Re: Holiday mailings

Re: Holiday mailings

Re: Holiday Mailings

Re: Holiday mailings

Re: Holiday mailings

Morley RAM disc

Morley RAM disc

EtherNet

Re:  EtherNet

Re: EtherNet

Screen Compression

Re: Screen Compression

IBM Reader

Econet

Re: Econet

BBC micro VT200 (plus) emulation?

BBC micro VT200 (plus) emulation?

BBC Micro VT100 emulation

BBC Micro VT100 emulation

Re: BBC Micro VT100 emulation

Re: BBC Micro VT100 emulation

My system has changed

A group project...

Re: A group project...

Re: A group project...

BBC File transfer

BBC File transfer

I see this list has got off to a flying start this term

Re: I see this list has got off to a flying start this term

My latest....

TequilaComm

Real Time Clock (and other stuff)?

Re: Real Time Clock (and other stuff)?

Re: Real Time Clock (and other stuff)? (fwd)

Re: Real Time Clock (and other stuff)?

Graphics Library+bits

Re:  Graphics Library+bits

Re:Real time clock, and BBC as a graphics terminal

Re: Re:Real time clock, and BBC as a graphics terminal

Re: Re:Real time clock, and BBC as a graphics terminal

Re: Re: Re:Real time clock, and BBC as a graphics terminal

Re:  Real Time Clock (and other subjects)?

beeb RTC

Forwarded Request

Me!

BBC on Desk!

Please add me to the BBC mailing list

re:32016, (+Teletex stuff)

Re: 32016, (+Teletex stuff)

Hello everyone

languages, in particular COBOL

Beebug 'C'

Beebug C and other things...

Minor progress on Pandora...

32016 Compiler (+others)

32016 Compiler (+others)

Cheapo network

Re: Cheapo network

Re: Cheapo network

Re: Cheapo network

Zany idea

Networks

Re: Networks

tequilacomm

Econet Printer servers

Reading/writing DOS disks

Re: Reading/writing DOS disks

Minimum configuration?

Re: Minimum configuration?

Re: Minimum configuration?

Re:  Minimum configuration?

BBC Mailing list: intro

DOSFS now at shiraz.ohm.york.ac.uk

Re: DOSFS now at shiraz.ohm.york.ac.uk

Problems with Small-C on BBC B

Re: Problems with Small-C on BBC B

Re: Problems with Small-C on BBC B

BBC network

DOSFS again

Smalltalk! (well almost!)

chip no longer needed

ANSI-C??

A new OS layer?

A new OS layer?

A new OS layer?

Relocation of 6502 images

Re: Relocation of 6502 images

Re: Relocation of 6502 images

broken ADFS floppys

Re: broken ADFS floppys

coprocessor memory map?

Re: coprocessor memory map?

Re: coprocessor memory map?

Teco ...

*RLOAD

Re: *RLOAD

Re: *RLOAD

editor blues

Re: AMPLE files (was: Relocation of 6502 images)

Re: AMPLE files (was: Relocation of 6502 images)

Re: AMPLE files

Re: AMPLE files

Re: AMPLE files (was: Relocation of 6502 images)

BBC: How long does Copyright last?

Re: BBC: How long does Copyright last?

Re: BBC: How long does Copyright last?

UUencode & archivers

Admin+Alpha software Release

Re: A new OS layer?

Re: A new OS layer?

BBC mailing list?

The big 4 0 !

BBC Master + 2nd processor

BBC Master + 2nd processor

SuperBEEB

Re: SuperBEEB

SuperBEEB

Re: SuperBEEB

Re: SuperBEEB

BBC Master + 2nd processor2

Equivalent for 8271 FDC?

Re: Equivalent for 8271 FDC?yes

A new thing...

Re: A new thing...

Re: A new thing...

A new thing...

Re: A new thing...

screens and modems and stuff

screens and modems and stuff

Re: GIF viewer

Re: GIF viewer

GIF viewer

BBC: Caps lock off via software?

BBC: Caps lock off via software?

BBC: Caps lock off via software?

BBC Caps lock thru S/W

shift/caps lock in s/w and sideways ROMs

BBC Caps lock thru S/W

UnZip 1.2

Mouse drivers?

OSWORD list?

OSWORD calls

new FTP archive

m/c optimisations

Re: m/c optimisations

Re: m/c optimisations

m/c optimisations

m/c optimisations

Small-C optimisation?

m/c optimisations

m/c optimisations

hdfs

Re: hdfs

hdfs

Optimisations.

Other Beebs

Other Beebs

Re: Other Beebs

searching for BBC envelope experiment program

Fast routine required

Fast routine required

Unrolling loops

Unrolling loops

Acorn Address

Re: Unrolling loops & fast routines

Re: Unrolling loops & fast routines

Unrolling loops & fast routines

Unrolling loops & fast routines

Re: Unrolling loops & fast routines

Unrolling loops & fast routines

Re: Unrolling loops & fast routines

Arithmetic routines

Re: Arithmetic routines

6502 C compiler

TequilaComm

Mouse-driven s/w

Beeb graphics

Colour Graphics

Colour Graphics

Colour Graphics

C-compiler beta release

Colour Graphics

Colour Graphics

Colour Graphics

BASIC V -> II or IV

Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Re: Tube connections (was RE: colour Graphics)

Tube for video enhancement...

Unix

Synchronous modem emulation

Micron EPROM Programmer info sought

PC DFS

Change of email address

Newbie on the list ;-)

Re: Newbie on the list ;-)

Re: Newbie on the list ;-)

Re: Newbie on the list ;-)

Forward

Re: Beebs and bits

Re: Beebs and bits

Second Processors

Hardware projects & Emulators

Re: Hardware projects & Emulators

Re: Hardware projects & Emulators

Free HD controllers

Beeb newsgroup

DES, RFS maker, UIM editor

NEED disc organizing software

introduction

Re: introduction

Re: introduction

Chess stuff

Re: Chess stuff

bbc winchester

ICS Client Software

Screen Dump

E(PSON)DUMP.A01 UPLOAD

EPSON DUMP

Bad disk drive

Re: Bad disk drive

PERSONAL INFO (FIRST POSTING TO THE LIST)

disks for BBC

BBC EMULATOR


Re: Beeb hard discs and host adaptor cards.
Date: Thu, 21 May 92 11:13:20 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: ian@ohm.york.ac.uk

Subject: Re: Beeb hard discs and host adaptor cards.

the cost is about 35 pounds fully built. This is a guestimate based on catalogue prices and pcb costs, but should be fairly right.

        This board connects direct to the 1 MHz bus, and the 'other side' of the board is a SCSI bus, which can, in principal connect to any SCSI device.

So far me and a friend have connected several different scsi devices and all have worked first time. Basically ANY scsci drive will work 100%, and I can't see anyone wanted to connect anything else?

        The ADFS fully supports the drives, providing they are formatted, which is done with several, alternative formatting programs, which are written in basic and actually do very little except issue the scsi format command,

and then write onto the disc the free space map and root directory.

The mailing list sounds very interesting, particularly if it is old acorns

only since then it isnt swamped by arc owners. I presume when it is fully up

and running you will post on comp.sys.acorn?

Will you put Dave Gilbert (gilbertd@uk.ac.man.cs.p4) on the list as well

please.

Hope this helps,

Richard.

:----------------------------------------------------------------------:

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     : :----------------------------------------------------------------------:


Re: Beeb hard discs and host adaptor cards/Mailing list
Date: Thu, 21 May 92 11:48:07 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: ian@ohm.york.ac.uk

Subject: Re: Beeb hard discs and host adaptor cards/Mailing list

Fine, I am making a couple of boards for friends at the moment, but now I know there is a bit of interest I will make a couple more at the same time.

My manchester address is

7 Kingswood Road

MANCHESTER

M14 6RZ

061 225 8625

and my home address (ie holidays)

'upperlands'

Milton Street,

Narborough,

LEICESTER

LE9 5EZ

0533 867926

the term ends about 21st of June.

mail me when you know what you want,

best wishes,

Richard.

:----------------------------------------------------------------------:

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     : :----------------------------------------------------------------------:


My interests etc...
Date: Thu, 21 May 92 17:53:03 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: My interests etc...

  OK, firstly, I own an issue 7 model-B with 16K s/w RAM and a single switchable drive (5.25 inch)

  Having got that out of the way, My interests are networking (a little difficult without an interface) and I do quite a lot of work in a school

with respect to this.

  My other main interests are Elite and trying to get together enough money to buy an Archimedes. (tho' this may be set back by the recent announcement of a SCSI interface for 35(ish) quid).

  In terms of wish lists, I could do with a Hard Drive (couldn't we all)

and a decent C compiler that supports floating point and can compile stand-alone code which is not HUGE (as small-C 0.70 does).

  OK, I think that's it. I'll post some problems which I'm having with a piece of software I'm trying to write if you like...It's a piece of code for reading the Econet  interface. I'll post more details when this group's got

a little more established...

Mik

P.S. Am I the first to post here?

P.P.S. - are we going to establish some standard for posting any software which is needed? - if so may I suggest the Intel Hex format 'cos I know that the coder/decoder for this is on lancs and I've got it, and it works...

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: My interests etc...
Date: Fri, 22 May 92 09:44:55 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: My interests etc...

As I set all this up, I guess I should tell you who I am, and why I'm  doing this.

I recently recovered my BBC from my parents house, and set it up  again. Basicaly it was great to get back to the old machine, and it's  still capable of doing many usefull things (at the very least, for  text entry). As I've said - I've got a pretty big workstation here at  work, so there's little point in buying a new home machine. It could  never be as fast/nice etc so I'll stick with the quirky "quaint"  macine I've got at the minute.

I've got an issue 3 model B, 48K s/w Ram + single switchable drive.  I've also got an AMX mouse and a Music 500. At the moment I've  borrowed a 6502 2nd processor, though I'm hoping to get a 32016 pretty soon. Once I've sussed that out, a hard dic upgrade is a  definite must (as the interface is only 35 quid as Mik pointed out -  prehaps you'd like to re-publisise it here Richard, just incase

anyone missed it).

I'd agree with Mik that a good C compiler would be VERY usefull,  though having a second processor, my problems with TinyC are

different - I particularly miss decent typing (structs, arrays etc).  I've got a patch to tinyC with customise it to the second processor,  in particular allowing the command line options to be read accross

the tube, which I'll make available if anyone is interested.

Reguarding posting software - if anyone is interested we can use my  machine as an ftp site (at least for a trial period) -  shiraz.ohm.york.ac.uk. I've placed a standard copy of tcc in there

for starters.

Does anyone have any contacts within Acorn or other software

companies that USED to distribute BBC software ? Would it be possible  to get tham to aggree to relax copyright on certain items which they  no longer support, allowing it to be copied as shareware or the such  like ? Basicaly no one is selling software any more, so would they  agree to, if not _let_ us copy it, aggree not to sue if we do...

I'd realy like to get a copy of 6502 Elite, now that I've got a  processor to play it on, but it wasn't exactly a big seller at the  time, and getting a copy now is near on impossible.

Anyway enough waffling

Ian Stephenson

P.S. List admin stuff should now be sent to  bbc-list-request@ohm.york.ac.uk


Re: My interests etc...1
Date: Fri, 22 May 92 16:03:50 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: My interests etc...

On Thursday May 21, 1992 Mik Davis <davism@uhura.aston.ac.uk> wrote:

>P.P.S. - are we going to establish some standard for posting any software

>which is needed? - if so may I suggest the Intel Hex format 'cos I know that

>the coder/decoder for this is on lancs and I've got it, and it works...

I can post my uuencoder and -decoder on this list, if you want. These are two small machine code programs which live in the usual buffers (&900 or so). Advantage is that you can also unpack the files on a Unix box, or on virtually any machine.

Now, my equipment... I have an Electron with a Plus 1, a Plus 3 and a Rombox. In the Plus 1 i have 32K Sideways RAM (battery-backed) and a Pace RS423 interface, connected to my modem.

My current project (for more than a year now, progress is a little slow) is

a terminal emulator with Ymodem file-transfer and ANSI emulation. Already

works quite nice.

Greetings all,

<>< Gerben.


My equipment & interests
Date: Fri, 22 May 92 10:39:31 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: My equipment & interests

Hello everyone,

I have a BBC B (issue 3 PCB), with a sideways ROM extension board with 16K RAM in the most important slot, but no battery back-up.

I upgraded the machine to use DFS myself when 8271s became available.  (At first it was faster to order a machine without disk interface, as the 8271 chip was on a longer lead time than anything else)

My trusty disk drive has just broken, and so I am considering getting a pair of 3" slimline drives, and transferring all of my files.  At the same time it might be an idea to attempt to upgrade to ADFS and a 1770. I lost access to my BBC when ADFS came out (I went to university and my time was being occupied in other ways). How compatible with DFS is it? Can I still play Elite from my Acornsoft disk? If not can I transfer it easily?

I have a Z80 second processor that I have never used, but will probably get around to playing with when I have the disk support.

I would like a hard-disk at some time, and the SCSI interface for 35 quid sounds like a real bargain - SCSI is so versatile (and I can probably borrow a tape streamer for backup purposes from work).

My interests include both H/W and S/W, but S/W tends to win as it is cheaper to play with than H/W! I am interested in a good "C" cross compiler/assembler/linker for either the 6502 or the Z80 (or both). It could execute on either, and would preferably come with the source. Especially nice would be a linker that had the facility to remove unreferenced functions from linked-in library modules, thus reducing the size of the executable.

Yours,

Matthew

matthew_sweet@tadtec.uucp


My equipment
Date: Fri, 22 May 92 12:13:04 BST

From: David Alan Gilbert <gilbertd@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: My equipment

Hi Everyone,

Well I've got 3 8 bit beebs:-

1) Series 3 board , BBC micro before they changed it to British Broadcasting Corp., which came with 0.1 in ROM and Basic 1, but has since been upgraded and now has, an ATPL board with 16K of non-battery backed ram, a watford shadow ram board, a PMS 64K battery backed ram disc on the 1MHz bus, and Acorn 8271 DNFS (1.20) with dual (full height) 100K drives.

It is used mainly for developing software for a little 6502 controller board I built.  I built an eprom emulator for around #20 which hangs off the user and parallel ports.  At one time a long time ago it had a 6502 second processor. Its 10 years old in September and still works most of the time.

2) Model B series 7 board - also with Acorn 8271 DNFS, and very little else on it.  The drives on it are dual full height 100tpi drives bought second hand (when I didnt know they were 100 tpi).  I really would be interested to know what machines used 100tpi drives. This was used in business for around 6 years running software off tape and then off the ROM Filing System until it was bought home about a year or two ago. This gets used mainly as a terminal for packet radio (on that note has anyone managed a really cut down TCP for the beeb?)

3) A master 128+512 board.  A more recent addition to the family, the 512 board is useless and was bought when it was only #99.  It has a pair of 800K drives on it.  This is mainly used for word processing in View now - somewhere around we have an AMX mouse and Pagemaker/Super Art.

I also have an Arc, but the beebs still get used regularly.

Dave ------------------------------------------------------------------------------- - David Alan Gilbert - gilbertd@p4.cs.man.ac.uk - G7FHJ@GB7NWP                - -------------------------------------------------------------------------------


someone mentioned ADFS
Date: Fri, 22 May 92 13:53:23 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: someone mentioned ADFS

  ADFS is not like DFS, But if you install ADFS, you can leave your DFS in there and still play Elite from your Acornsoft disc (like wot I do xcept I don't have an ADFS (yet))

  also I hope you don't mean 3" drives...especially as most beeb s/w comes on 5.25"

Mik

PS Sorry I can't remember who asked about this

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


My beeb setup and SCSI interface
Date: Fri, 22 May 92 14:25:46 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: My beeb setup and SCSI interface

hi,

   I am the 'famed' producer of the SCSI interface which everyone seems to be interested in :-) As has been mensioned several times by now the price will be about 35 pounds, although I'm not sure how much it would cost to send it abroad. For the record my address at Manchester (University) is;

7 Kingswood Road,

MANCHESTER

M14 6RZ

061 225 8625

and my home (holiday) address is;

'Upperlands'

Milton Street,

Narborough,

Leicester.

LE9 5EZ

0533 867926

Also for the record I am technical advisor for Solinet, the beeb user group, originally set up to support Solidisk (STL) products, but now covering everything that has an Acorn badge on it! I will post the editors name and address when I remember.

My setup consists of;

Issue 7 model B,

STL 32K 4 meg board (runs processor @ 4MHz, with lots of SWR and

Shadow),

Replay system (Vine Micros),

Quest mouse + paint (excellent, incase anyone is wondering)

SCSI host card plus 44 Meg SyQuest removable hard drive,

2*80 track doublew sided drives,

STL 1770 DDFS interface.

2 inch fan mounted in the beeb lid :-) (no I'm not kidding)

And of course about 100 ROM images ;-)

As you can imagine taking it home at the end of term is lots of fun!

I will probably post a full bit on the SCSI card next week.

Can I sugest someone keeps a copy of these 'bits' lists, so its easier to contact people with similar equipment. It could then be automatically be sent to new subscribers. Any offers?

Richard York.

:----------------------------------------------------------------------: : Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    : : 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    : : Manchester University          :                                     : :----------------------------------------------------------------------:


Re: bit lists - who has what..
Date: Fri, 22 May 92 14:38:18 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: bit lists - who has what..

Yes - a good idea.

I'm currently keeping ALL traffic thats going through the list, I'll  make up a list of this stuff, and make it available for ftp in a few  days.

I don't know if its worth keeping a long term archive of ALL traffic,  but if I'm feeling usefull I might diguest the most intresting stuff  and archive that too.

Ian


Someone on monochrome mentioned a mailing list on bitnet
Date: Fri, 22 May 92 14:53:31 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Someone on monochrome metioned a mailing list on bitnet

ACORNL or something...anyone know anything about it?

I'll upload some s/w to the ftp server soon if I can convince our departments only (and slightly decrepid) model-B to read my disks...

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


acorn-l
Date: Fri, 22 May 92 16:08:33 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: acorn-l

On Friday May 22, 1992 Mik Davis <davism@uhura.aston.ac.uk> wrote:

>ACORNL or something...anyone know anything about it?

acorn-l@grearn.bitnet - send a message with "sub acorn-l Your Full Name" in

its body to listserv@grearn.bitnet to subscribe.

I have done this recently, but received no answer at all, so i'm afraid

the list is defunct. Does anyone know someone who reads that list?

<>< Gerben.

acorn-l


Re: acorn-l
Date: Mon, 25 May 92 10:05:08 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: acorn-l

I just receiveed the following mail:

From: Dag H}kon Myrdal <dhmyrdal@solan.unit.no>

Date: Sat, 23 May 92 03:20:08 +0200

To: ian@ohm.york.ac.uk

Subject: Re: 8 - bit Mailing List

Newsgroups: comp.sys.acorn

In-Reply-To: <1992May22.100248.6228@ohm.york.ac.uk>

Organization: University of Trondheim

There is also the BITNET mailing list ACORN-L...

This has *very* low traffic for the time being, so maybe there really should be only one?

Subscribe to it by sending email to:

LISTSERV@GREARN.BITNET

containing:

subscribe ACORN-L

Send articles to:

ACORN-L@GREARN.BITNET

--Dag

However things are going pretty well here(in response to Patrick's  question there are 18 people on the list - I just added five this  morning), so I propose to keep things exactly as they are. I expect  traffic may die off a little once the initial rush of introductions  is over, but I think that there are  enough people enthusiastic  enough to make thing happen.

Ian


SCSI
Date: Fri, 22 May 92 11:04:54 BST

From: Patrick Clark <csuaw@csv.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: SCSI

Mathew Sweet writes:

[]

I would like a hard-disk at some time, and the SCSI interface for 35 quid sounds like a real bargain - SCSI is so versatile (and I can probably borrow a tape streamer for backup purposes from work).

[]

Yours,

Matthew

matthew_sweet@tadtec.uucp

My question is, What is this interface ? I would love a hjard drive for my trusty old beeb, and SCSI would be a way to go, but from what Ive heard it would be incredibly difficult (and expensive to do). An interface for 35 quid does sound a bargain !

Another question, Who is on this list / how many people on the list ?

Just curious really !

Cheers,

Patrick Clark.

-- ______________________________________________________________________________ Patrick Clark          |P.M.Clark@uk.ac.warwick     | 'In Europe and America University of Warwick  |  patrick@uk.ac.warwick.dcs | theres a growing feeling Coventry , CV4 7AL     |    csuaw@uk.ac.warwick.csv | of hysteria. ' - Sting


The mailing list (surprisingly)
Date: Fri, 22 May 92 14:56:44 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list-request@ohm.york.ac.uk

Subject:  The mailing list (surprisingly)

   Would it be possible to arrange for the list server to change the From: line of the header to something standard to make it easier to sort out

from my personal mail?

   Not knowing much about how you're doing this, I don't know

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


All the info you wanted but where afraid to ask
Date: Fri, 22 May 92 18:30:12 BST

From: Jason O'Broin <J.P.O'Broin@durham.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: All the info you wanted but where afraid to ask

Exam's over - time to fill you in on my Beeb setup.

BBC Model B. Issue 7. OS 1.2

Solidisk 1770/8271 switchable disk controller board (This allows me to use DFS with the 8271 to be *totally* compatable with everything and ADFS with 1770) ATPL Rom Board - 16K RAM + host of roms inc. my own Eprom Programmer - if anyone wants any EPROMs blown, I'll be happy to over the summer

Dual 40/80 5.25" floppy

Think that's about it really

To be honest, I haven't used my Beeb much in the last 2 years - have been using all my Arc all the time. Sorry :-)

However, I have got some homebrew software that might be of interest.

The main one is an IBM disk reader - requires Master on Beeb with 1770 interface. Reads ok, but doesn't write. Can cope with IBM subdirs.

Econet: *OPEN...if you use SJ Econet and try to open a file which another user has already opened to write to, it bombs out on you, trashing the stack and other nefarious features. *OPEN traps this, and returns gracefully with file handle of 255  Comms: Xmodem if anyone fancies this. I still use it under the Tube emulator on the Arc to transfer files.

I actually used a beeb again during the Christmas term for my Physics project - it was quite fun to come back to 6502 after all this time!!

Jason

J.P.OBroin@uk.ac.durham


Re: All the info you wanted but where afraid to ask
Date: Mon, 25 May 92 17:18:18 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: All the info you wanted but where afraid to ask

On Friday May 22, 1992 Jason O'Broin <J.P.O'Broin@durham.ac.uk> wrote:

>However, I have got some homebrew software that might be of interest.

>The main one is an IBM disk reader - requires Master on Beeb with 1770 >interface. Reads ok, but doesn't write. Can cope with IBM subdirs.

Would it be possible to port this to the Electron (just change the addresses of the interface?), or not?

I bet it would be hard if the program intercepts interrupts or even NMIs, and i don't know much of the Electron ADFS internals.

>Comms: Xmodem if anyone fancies this. I still use it under the Tube emulator >       on the Arc to transfer files.

My comms program, TSTerm 0.43 (with Ymodem) will be available on rusinfo.rus.uni-stuttgart.de soon.

Greetings,

<>< Gerben.


IBM Reader1
Date: Tue, 26 May 92 10:41:55 BST

From: Jason O'Broin <J.P.O'Broin@durham.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: IBM Reader

 Gerben,

 Had problems mailing you direct - so I'll send the reply through the

 list. It might interest someone else as well :-)

 >On Friday May 22, 1992 Jason O'Broin <J.P.O'Broin@durham.ac.uk> wrote:

 >

 >>However, I have got some homebrew software that might be of interest.

 >

 >>The main one is an IBM disk reader - requires Master on Beeb with 1770

 >>interface. Reads ok, but doesn't write. Can cope with IBM subdirs.

 >

 >Would it be possible to port this to the Electron (just change the

 >addresses of the interface?), or not?

 >I bet it would be hard if the program intercepts interrupts or even NMIs,

 >and i don't know much of the Electron ADFS internals.

  I should think it'll be easy. The NMI routine should be the same, and

  all you need to change is the addresses it uses to access to 1770 chip.

  My program has two set of address in it - the first BBC B+ compatable,

  the second Master compatable.

  The ADFS internals are un-important.

  I'll did it out when I go back home.

 >Greetings,

 >	<>< Gerben.

 >

Jason.


Introductions
Date: Fri, 22 May 1992 23:00 GMT

From: John Whistler <JOHN_W@vulcan.mentec.ie>

To: bbc-list@ohm.york.ac.uk

Subject: Introductions

Seeing as we are all introducing ourselves, here is my list of hardware

& interests:

BBC 'B' Issue 7

Acorn DFS & 2 80-track floppies (one switchable)

Torch Z80 2nd Processor

Acorn 6502 2nd Processor

Solidisk 256k board

Watford Sideways ROM board

My interests are programming, educational software & games.

The beeb is currently in pieces in the attic. I'm converting part of the attic as a 'computer room', and as soon as that's ready (RSN), I'll re-assemble it.  After the great re-assembly, I hope to get one of these SCSI interfaces which I've been reading about.

John Whistler.     Internet: john_w@vulcan.mentec.ie


Introductions1
Date: Sat, 23 May 92 15:07:01 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject: Introductions

Hello all,

Seeing as we are all introducing ourselves, here's my lot!

BBC Master 128K

80186 512K Co processor - does an ok job of PC emulation

1 switchable 40/80 track 800K drive

1 80 track 800K drive

A modem - v21/v23 - very old but I got it cheap

A printer

I mainly use the machine for word processing, programming and logging on to

my College's Unix  machine.

Like everyone else I like what I hear about the SCSI interface.

I also have an old(very) Wang pc and I wondering how to connect the two together

Talk to you all soon ,

Stephen.


A bit about me and my kit.
Date: Sun, 24 May 92 00:47 GMT

From: Alan Ralph <aralph@cix.clink.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: A bit about me and my kit.

At the moment I've got a Master 128, with a Turbo Co-processor Board, and Morley AA ROMboard inside. Outside there's a Morley Smart Cartridge, a switchable 40/80T disk drive, a Hi-Tec EC2400 modem, a Music 5000, a Morley Hard Disk, and a Star LC-200 printer. Oh, and a monitor currently on it's last legs.

I'd love to have an Archie if I could afford one, but as I'm currently unemployed that's a bit of a problem! So I'm stuck with the Master for now.

Believe it or not, I actually read Usenet OFF-LINE, on my Master, with a little help from the EDIT command of the View word-processor.

I'm co-moderator of the BBC conference on CIX, the Compulink Information eXchange, which is pretty quiet these days. I also read, and occasionally contribute to, the BBC Echo on FidoNet (still going strong, just) via the World of Cryton BBS.

Amongst the mountain of software in my possession is a PD package called ATerm, which does a pretty good ANSI emulation coupled with up/download capability up to Ymodem-G (sorry Gerben, but you're not the only one to have had that idea.) I have Gerben's Arc and UUencode here, so I could post it if anyone want me too.

I'll spread the word, and see if I can rattle up some more support.

Alan.


tcc via !65host on a acorn archimedes ?
Date: Mon, 25 May 92 11:17:44 MST

From: Joerg.Scheurich@rus.uni-stuttgart.de (MUFTI)

To: bbc-list@ohm.york.ac.uk

Subject: tcc via !65host on a acorn archimedes ?

Hi

Has someone also tried to use tcc via !65host on a acorn archimedes ?

I tried it and it fails in as65 ....

Has some any other tried to install it ??

so long

MUFTI

From: Dag H}kon Myrdal <dhmyrdal@solan.unit.no>

Received: by solan10 ; Sat, 23 May 92 03:20:08 +0200

Date: Sat, 23 May 92 03:20:08 +0200

Message-Id: <9205230120.AA20408@solan10>

To: ian@ohm.york.ac.uk

Subject: Re: 8 - bit Mailing List

Newsgroups: comp.sys.acorn

In-Reply-To: <1992May22.100248.6228@ohm.york.ac.uk>

Organization: University of Trondheim

In article <1992May22.100248.6228@ohm.york.ac.uk> you write:

>A Mailing list for Acorn's 8-bit BBC machines is now operational. To subscribe,  >contact:

>bbc-list-request@ohm.york.ac.uk

>

>The main list address is:

>bbc-list@ohm.york.ac.uk

>

>Hope to hear from you soon...

>

>Ian Stephenson

There is also the BITNET mailing list ACORN-L...

This has *very* low traffic for the time being, so maybe there really

should be only one?

Subscribe to it by sending email to:

LISTSERV@GREARN.BITNET

containing:

subscribe ACORN-L

Send articles to:

ACORN-L@GREARN.BITNET

--Dag


New Member
Date: Mon, 25 May 92 10:38:06 BST

From: Thomas J Hughes <thughes@dcs.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: New Member

As I've just joined this group, I'd better give people an idea of my setup (not that I've got it here anyway). It's a Master 128 with very little added apart from a disc drive and monitor. I also have the Replay system installed with the OS1.2 addition, so I can have a stab at running old model B stuff which don't work on the master. Finally,I have the Macrom macro assembler installed.

You might also like to know that I intend to post a couple of my programs to comp.binaries.acorn in the next few days - I'm just waiting for an Arc owning friend of mine to transfer them to a PC floppy for me, so that I can upload them to Unix.

Hope this forum is a success.

Tom.

============================================================================ Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


No Subject
Date: Tue, 26 May 92 11:14:41 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject:

erm...sorry I can't remember your name (Richard?) but this is mainly aimed

at the builder of those SCSI interfaces (who is going to be very busy soon I think...)

Here's a couple of questions:

  1) How does it cope with multiple drives (i.e. more than 2)?

  2) How does it cope with things like tape streamers?

  3) How does it cope with removable media?

  I think I knwo the answer to the last one but I thought that ADFS restricted the number of hard drives you could have and not kowing much about SCSI OR tape streamers, I don't know about 2)

Thanks

Mik

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


DOS reader
Date: Tue, 26 May 92 11:10:12 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: DOS reader

  I'm afraid my mailer is refusing to include text at he mo. but someone mentioned porting the DOS reader to an electron...

two questions:

1) is it legal

2) would it go to a Model B (not a +)

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


SCSI interface board.
Date: Tue, 26 May 92 12:04:45 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: SCSI interface board.

A few questions have been made about what the SCSI interface card does.

Perhaps now is a good time to describe it a little more fully.

Firstly Acorn ADFS is 'hard wired' for SCSI device 0. It is easy to adjust so that is uses a different device, but the fixed device number remains. Currently multiple drives are supported using the LUN terminology. This system was chosen because in the days of the conception of ADFS SCSI drives were very rare. The system instead used SASI (a subset of SCSI, and infact what SCSI was based on) cards, which drove ST506 drives. This is how part of my system is built, although as I have said previously I now have a SyQuest drive connected direct to the host card, ie my SASI to ST506 card (Zebec 1410a for the record) is currently unused. Anyway these cards normally supported two drives (normally they had to be of the same type and size), and the LUN was used to select between them. Hense drive 0 is SCSI device 0, LUN 0, drive 1 is SCSI device 0, LUN 1 etc.

I have done some exploritary work on the ADFS with SOLIMON and have worked out the critical SCSI bus access code, so it COULD be possible to add support for multiple SCSI drives. However it would not be easy since;

a) ADFS 1.3 is TOTALLY full.

b) SCSI access code is duplicated in several places.

c) How is multiple drive support added? (probably converting LUN to device number)

The question however must be asked; WHY whould you want more than one drive??

I certainly can't see any need for it. After all very cheap drives of around 20-40 Meg can be bould, which should be enough for any purpose I can think of.

Don't forget the drive can be partitioned for use with the Master 512, exactly like with the PC emulator on the Arc. The program is I believe provided with the 512, but I have a friend who has a program (published in Acorn User) which allows partitions to be created of arbitary size, which is much better than the Acorn offering.

The partition is simply a file of the required size created in the ADFS file structure, so it doesn't affect the normal ADFS operation at all.

TAPE STREAMER SUPPORT.

In principal it will work, in that the SCSI commands can be sent to the device, just as with a normal drive. However tape streamers use a slightly modified class of SCSI instructions which ADFS I don't think would be able to cope with. I suppose a piece of software could be written to create an ADFS filing system on the tape drive, but it would not be easy. Also the problem of 2 seperately addressable SCSI devices on the same bus would be a problem.

REMOVABLE HARD DRIVES.

These are obviously supported (I'm using one aren't I :-) ), but really this doesn't mean Acorn went out of their way to do it; just that they look exactly like a normal drive, except that certain commands respond slightly differently. For example issuing *BYE spins down the cartridge ready to eject it. I presume on a non-removable drive the particular command issued causes the SCSI drive to park its head, though I'm not sure.

Also I can issue a SCSI command to lock the cartridge and relase it, though I can't see any benefit in doing this.

GENERAL SCSI NOTES.

Osword &72 is effectively the "issue a SCSI command" OS call, and it works well. All the above calls (spin down drive etc) can be issued using this route, just as long as you know what command to issue :-) A SCSI standard helps!!!

Lots to chew over here. Basically its easy, and fairly foolproof. All you

need is the host card, PSU, SCSI drive and something to put it in.

Hope this helps,

Richard York.

:----------------------------------------------------------------------:

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     : :----------------------------------------------------------------------:


BBC Master IBM disc reader query
Date: Tue, 26 May 92 13:13:59 +0100

From: ic1@ukc.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: BBC Master IBM disc reader query

Hi

I was wondering if any one can help me out regarding the IBM disc reader for the BBC master. I would dearly like to get hold of this program. Is it PD software ? Is it available for ftp ?

Thanks in advance,  ian.


Comms program
Date: Wed, 27 May 92 01:40:51 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Comms program

I'm having some trouble distributing my comms program, but I hope to make it avaliable shareware soon somehow...

Gerben 'P' Vos <gpvos@cs.vu.nl> writes:

> My comms program, TSTerm 0.43 (with Ymodem) will be available on

> rusinfo.rus.uni-stuttgart.de soon.

This is interesting, is it for the 8 bits? I had some thoughts of doing Zmodem, but decided ymodem is really everything you need...

I've written an Unzipper too, handling "implode" only so far. the Zip program

is on hold, as my current project is a filing system for a hard drive. I'm doing that the hard way, I want all te workspace to be in sideways ram, so

need to write a whole new FS.

I have a model B, with 64k of sideways ram. I made the sideways ram very cheaply, and can give details if people want...

Finally, Hi All!

Dave.


Re: Comms program
Date: Wed, 27 May 92 1:53:41 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: Comms program

On Wednesday May 27, 1992 Dave Sainty <terros@sideways.welly.gen.nz> wrote:

>I'm having some trouble distributing my comms program, but I hope to make it >avaliable shareware soon somehow...

I'd like to see it! As is always the case: when the time is right, several people invent the wheel at the same time. As soon as my program worked reasonably, i found three other comms programs with Ymodem! But two of them didn't run on my machine...

>Gerben 'P' Vos <gpvos@cs.vu.nl> writes:

>> My comms program, TSTerm 0.43 (with Ymodem) will be available on

>> rusinfo.rus.uni-stuttgart.de soon.

>This is interesting, is it for the 8 bits? I had some thoughts of doing Zmodem,

>but decided ymodem is really everything you need...

Well, Zmodem works better in some instances (like when some strange

terminal server like the one here in Amsterdam tries to "intelligently"

buffer your file...).

It works on my Electron and on at least one BBC-B. Later versions (not released yet) read the VDU workspace (page &300) directly to make ANSI emulation

simpler, so these are guaranteed not to work across a Tube.

** Question for all: is the allocation inside page &300 the same in all Acorn

** eight-bit machines?

Oh yes, last time i forgot to mention my main interests. They are programming

and datacommunication (if you hadn't already guessed).

Greetings,

<>< Gerben.


Re: Comms program1
Date: Thu, 28 May 92 18:02 GMT

From: Alan Ralph <aralph@cix.clink.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Comms program

Gerben 'P' Vos <gpvos@cs.vu.nl> writes:

>On Wednesday May 27, 1992 Dave Sainty <terros@sideways.welly.gen.nz> wrote:

>>I'm having some trouble distributing my comms program, but I hope to make it-

>>avaliable shareware soon somehow...

>I'd like to see it! As is always the case: when the time is right, several >people invent the wheel at the same time. As soon as my program worked >reasonably, i found three other comms programs with Ymodem! But two of

>them didn't run on my machine...

Perhaps we'd better make a list of who's produced what, what capabilities each program has so far, and compatability with various machines.

So far I've counted yours and Dave's, plus the one I use, Gareth Babb's ATerm 0.79 (SWR version - also available in TTY and ANSI main-memory versions). Oh, and a 4-colour version of same, which has to be seen to be believed.

All these can handle ANSI emulation and are at or working towards Ymodem transfer. Any others?

>>Gerben 'P' Vos <gpvos@cs.vu.nl> writes:

>>> My comms program, TSTerm 0.43 (with Ymodem) will be available on

>>> rusinfo.rus.uni-stuttgart.de soon.

>>This is interesting, is it for the 8 bits? I had some thoughts of doing Zmod- em,

>>but decided ymodem is really everything you need...

>Well, Zmodem works better in some instances (like when some strange

>terminal server like the one here in Amsterdam tries to "intelligently"

>buffer your file...).

>It works on my Electron and on at least one BBC-B. Later versions (not >released yet) read the VDU workspace (page &300) directly to make ANSI >emulation simpler, so these are guaranteed not to work across a Tube.

ATerm will work across the Tube, at least for straight access - file transfer, especially at high speed, tends to fail tho.

>** Question for all: is the allocation inside page &300 the same in all Acorn-

>** eight-bit machines?

In a word, no. Here's the list of differences, taken from the 'Advanced Reference Manual for the Master 128' :

       Model B & B+                    Master 128

&359   Foreground graphics colour      Plotting foreground/background

&35A   Background graphics colour      Current graphics plot mode

&366   Mode 7 cursor                   Cursor control flags (VDU 23,16)

&367   Exploded font flag              Dotted line pattern (VDU 23,6)

&368   Exploded font location bytes    Current dotted line state

&369   Plot colour (0- solid, not 0- pattern)

&36A                                   F/grnd col. (0- solid, not 0- pattern) &36B                                   B/grnd col. (0- solid, not 0- pattern) &36C                                   Col. 81 flag (top bit set pending)

&36D                                   Foreground graphics colour

&36E                                   Background graphics colour

Hope that helps.

>     <>< Gerben.

Alan.


Re: Comms program2
Date: Mon, 1 Jun 92 17:14:03 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: Comms program

On Thursday May 28, 1992 aralph@cix.clink.co.uk wrote:

>>Question for all: is the allocation inside page &300 the same in all Acorn- >>eight-bit machines?

>In a word, no. Here's the list of differences, taken from the 'Advanced >Reference Manual for the Master 128' :

>       Model B & B+                    Master 128

[...]

Thanks a lot. I do indeed use some of these locations, so i'll have to add a check for the Master. Because of this, the program will be slower on such a machine, since i can't poke into the VDU system directly anymore, and i'll have to fall back on making 128 VDU 23's... Or is there a way to stuff the data into the right location without going through the VDU handler?

My program runs in sideways RAM, so it may be difficult.

Do you know how to check if your program is running on a Master? The INKEY call should return a unique value. Do you know what it is on a Master?

Greetings,

<>< Gerben.


Re: Comms program3
Date: Tue, 2 Jun 92 21:01 GMT

From: Alan Ralph <aralph@cix.clink.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Comms program

Gerben 'P' Vos <gpvos@cs.vu.nl> writes:

[Stuff about diffs. in VDU workspace between BBC B(+) and Master]

>Thanks a lot. I do indeed use some of these locations, so i'll have to add

>a check for the Master. Because of this, the program will be slower on

>such a machine, since i can't poke into the VDU system directly anymore,

>and i'll have to fall back on making 128 VDU 23's... Or is there a way to

>stuff the data into the right location without going through the VDU

>handler? My program runs in sideways RAM, so it may be difficult.

On the Master, the current character definitions are held in Private RAM from &8900 to &8FFF. The observant amongst you will have spotted that this lies on top of the space occupied by Sideways ROM or RAM. However, your Sideways RAM code can access it, provided you don't need to call subroutines from &8400 to &8FFF, with the following code:

LDA &F4

PHA              \ preserve current ROM number

ORA #&80

STA &F4          \ essential to do this first

STA &FE30        \ select sideways RAM

(your code)

PLA

STA &F4          \ restore original ROM

STA &FE30

RTS

(Note: The character definitions in this instance are for the range &20 to &FF)

>Do you know how to check if your program is running on a Master? The INKEY

>call should return a unique value. Do you know what it is on a Master?

On a Master (and Compact), the value returned by INKEY(-256) will be 253.  In machine code that becomes A=&81, X=0, Y=255, call OSBYTE, and X=whatever.

Let me know how you get on.

-Alan.


Re: Re: Comms program
Date: Mon, 1 Jun 92 19:03:57 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Re: Comms program

 >

 >      On Thursday May 28, 1992 aralph@cix.clink.co.uk wrote:

 >

 >      >>Question for all: is the allocation inside page &300 the same in all Acorn-

 >      >>eight-bit machines?

 >

 >      >In a word, no. Here's the list of differences, taken from the 'Advanced

 >      >Reference Manual for the Master 128' :

 >

 >      >       Model B & B+                    Master 128

 >      [...]

 >

 >      Thanks a lot. I do indeed use some of these locations, so i'll have to add a

 >      check for the Master. Because of this, the program will be slower on such a

 >      machine, since i can't poke into the VDU system directly anymore, and i'll

 >      have to fall back on making 128 VDU 23's... Or is there a way to stuff the

 >      data into the right location without going through the VDU handler?

 >      My program runs in sideways RAM, so it may be difficult.

 >

 >      Do you know how to check if your program is running on a Master? The INKEY

 >      call should return a unique value. Do you know what it is on a Master?

 >

 >      Greetings,

  I think the value for a master is 256 but I'm certainly not convinced about this

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


My set up
Date: Wed, 27 May 1992 08:43:39 +1000

From: daniel@yoyo.cc.monash.edu.au (Daniel Bowen)

To: bbc-list@ohm.york.ac.uk

Subject: My set up

Well, just for a kick-off, here's what Beeb bits and pieces I've got:

- BBC Model B (Issue 7), mono monitor

- Watford "Solderless" Sideways ROM/RAM board with 16Kb sideways RAM

- Watford Shadow RAM board (32Kb)

- 80 track disc drive (allegedly double sided, but side 2 won't work..)

- 2400 baud modem

- AMX Mouse

- Watford Video Digitiser

Roms:   (in order of me remembering them)

- Acorn DFS 1.20

- Basic 2

- ISO Pascal

- Beebug C

- View 2.1

- Viewsheet

- Shadow RAM OS

- AMX Pagemaker / Pagemaker Support ROMs

- MegaROM

(Probably one or two others I've forgotten.. hmm.. two at the most!)

And here's my question: I want a new disc drive. Do I have to hunt high and low for a 720Kb drive (5.25"), or can I just plug in an IBM 1.2Mb drive, which is easy to find and cheap..?

Daniel Bowen

--

Daniel Bowen, Monash University |

            Melbourne Australia |           I think fishing

   daniel@yoyo.cc.monash.edu.au |          is a load of carp.

      TCWF: tcwf@gnu.ai.mit.edu |                                 [TCWF 80]


What disk drive? (was My set up)
Date: Thu, 28 May 92 18:02 GMT

From: Alan Ralph <aralph@cix.clink.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: What disk drive? (was My set up)

Daniel Bowen <daniel@yoyo.cc.monash.edu.au> writes:

>And here's my question: I want a new disc drive. Do I have to hunt high >and low for a 720Kb drive (5.25"), or can I just plug in an IBM 1.2Mb >drive, which is easy to find and cheap..?

Good question... I suspect that you should be able to use a 1.2MB drive, once you have a case and/or PSU for it, and the necessary data cable. I can't imagine the data connection being too different from a 720K drive.

If the above is hogswash, could someone say so please?

>Daniel Bowen

Alan.


Re: What disk drive? (was My set up)
Date: Fri, 29 May 1992 07:02:49 +1000

From: daniel@yoyo.cc.monash.edu.au (Daniel Bowen)

To: bbc-list@ohm.york.ac.uk

Subject: Re: What disk drive? (was My set up)

On May 28,  6:02pm, Alan Ralph wrote:

> Daniel Bowen <daniel@yoyo.cc.monash.edu.au> writes:

> >And here's my question: I want a new disc drive. Do I have to hunt high

> >and low for a 720Kb drive (5.25"), or can I just plug in an IBM 1.2Mb

> >drive, which is easy to find and cheap..?

>

> Good question... I suspect that you should be able to use a 1.2MB drive,

> once you have a case and/or PSU for it, and the necessary data cable. I

> can't imagine the data connection being too different from a 720K drive.

>

> If the above is hogswash, could someone say so please?

I've now been told that the recording/reading technique on 1.2Mb drives differs from that on 720K drives.. I forget the jargon.. MFM or

something. So anyway, no, it can't be done.

Daniel

--

Daniel Bowen, Monash University |

            Melbourne Australia |          POPE GETS GRIT IN MOUTH!

   daniel@yoyo.cc.monash.edu.au |

      TCWF: tcwf@gnu.ai.mit.edu |                                 [TCWF 78]


8271->1770 upgrade
Date: Thu, 28 May 92 09:37:34 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: 8271->1770 upgrade

Hi all,

I am thinking of upgrading my 8271 to a 1770, and I have a few questions.

I currently have disc doctor. Does anyone know if disk doctor gets information from the DFS or if it directly accesses the 8271?

I believe that Elite might directly access the 8271(I have an early version: I bought it when it came out). Does anyone know if this is the case?

I have a DNFS ROM rather than a DFS ROM. When I got the DNFS ROM I believe it was required in ECONET disk servers for some reason. Is this correct? If so is it possible to get a DDNFS and ADNFS ROM?

Are there likely to be any other areas of incompatibility that I have missed?

Yours,

Matthew

matthew_sweet@tadtec.uucp


Music 500(0) and other ramblings
Date: Thu, 28 May 92 10:35:58 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Music 500(0) and other ramblings

Seeing as the first flurry of intro's is over I'll throw out a quick  query.

Has anyone any ideas about how to drive the Music 500(0) without using ample. I remember that hybrid used (they were still in business  12 months ago) to sell a rom which redirected sound commands to the synth, rather than to the internal circuit. Has anyone actualy used  it?

I've got the thing when it was still the 500, and was pretty  impressed. I did get a pirate copy of the 5000 stuff, and it's VERY  impressive, but naturaly there was no upgrade path ad no manuals for  it. I very seriously considered bying a legit copy, as I wanted to use midi. Unfortunantly I would have to upgrade to a legit copy first, then buy the midi upgrade. Even then it wouldn't take midi  input data. It was going to cost about 300 pounds, and even then I  would have to pay extra if I wanted to use a keyboard with it. I  decided this was a little silly, just for a half working midi  interface!

Despite the above (which may sound a little disillusioned with the  system) I think it was/is a great box, though without midi its a  little useless to me now as a way of playing music. It would be nice  to get it to make the odd noise now and then though. I remember  examining the code, and found that it used extended (it that the right word) paged memory in "jim" to store what I would asume are wave tables. Unfirtunatly I never got any further than that, as it all got a little complex.

I noticed there were a few people who claimned to have the boxes so  what do you use them for ?

Ian.

PS. I've added a few more people to the list - there are now 24.

PPS. Should be getting my 32016 REAL soon :-) comments to follow...


Re: Music 500(0) and other ramblings
Date: Thu, 28 May 92 22:12:02 +1300

From: Pat Cain <cain_p@kosmos.wcc.govt.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Music 500(0) and other ramblings

Well, here's my intro and reply to Ian.

Intro...

I run Sideways BBS (sideways.welly.gen.nz) which is currently running on a cheap PC.  Sideways is (believe it or not) named after sideways ram on the beeb--we must have been desperate for a name back in 1988.  Sideways used to run on my BBC Master under EBBS on 2x640k ADFS discs.  I had wanted to put a hard drive on the Master and run the BBS on that, but my power supply died and then I had many other nasty problems with the machine and it was out of action for around 2 years.  In that time I bought a cheap PC for the BBS to run on.

Now, this BBS here used to have packs of BBC software on it but we ran out of disc space so had to move the software to tornado.welly.gen.nz (neither sideways or tornado are directly connected to internet, so you can't ftp to them, only mail..) I will be getting a bigger hard disc for this PC soon and will move the BBC software back here and write a mailserver so people can request it via e-mail, though I suppose I'll have to kill off all the pirated games to keep out of trouble.

My BBC Master has a 512 board, mono monitor, 32k extra SRAM, and the Music 87/500/5000.

Ian writes:

> Has anyone any ideas about how to drive the Music 500(0) without

> using ample.

>

> I've got the thing when it was still the 500, and was pretty

> impressed. I did get a pirate copy of the 5000 stuff, and it's VERY

> impressive, but naturaly there was no upgrade path ad no manuals for

> it.

I bought the 5000 stuff years ago and haven't used it for sometime as my Master was out out action--fixed now, fortunately.  You're welcome to have a copy of my software (hope Hybrid don't read this :-).  I've got lots of ADFS discs of 5000 programs from the Ample user group but gave up subscribing to them after my Master died.  I didn't bother with MIDI for various reasons, a friend who was considering a 5000+midi bought an Atari ST and later Archimedes with MIDI.

I don't know anything about using the 500/5000 without the AMPLE rom, though the infamous Orlando apparently did quite a bit of work on playing music without the Ample rom.


Re: Music 500/0 +
Date: Thu, 28 May 92 23:05:04 EST

From: Andrew Alf Leahy <A.Leahy@st.nepean.uws.edu.au>

To: bbc-list@ohm.york.ac.uk (beeb mailing list)

Subject: Re: Music 500/0 +

> Seeing as the first flurry of intro's is over I'll throw out a quick

> query.

Since I've just joined...I'll give you a quick intro to my setup:

BBC Model B, 128K Sideways RAM, 2x80T FD, Music 500 + 5000 s/w, plus

Music 2000 (MIDI) driving a Roland D-110 module.

> input data. It was going to cost about 300 pounds, and even then I

> would have to pay extra if I wanted to use a keyboard with it. I

> decided this was a little silly, just for a half working midi

> interface!

There was some discussion in Amplinex (Ample User Group) about using the M2000 as I/P (instead of the usual O/P)...I never got the s/w quite working (then again I don't have a MIDI keyboard handy). I don't know if Amplinex progressed any further, since I haven't bothered sending over for any

discs for more than a year now.

> I noticed there were a few people who claimned to have the boxes so

> what do you use them for ?

Not a helluva lot these days. I'm hoping, when/if I get an Arc I'll be

able to better use the D-110. If anyone has any AMPLE s/w they'd be willing to swap I'd like to hear from them, particularly Amplinex discs after

issue #16 (Mar '91)....thanks. __________________________________________________________________________ Andrew "Alf" Leahy                                 phone: (047) 360671 (W) Uni. Western Sydney, Nepean.               fido: 3:713/601  irc: pepsi-alf Sydney, Australia.                  email: alf OR alf@st.nepean.uws.edu.au


Hi there
Date: Thu, 28 May 1992 15:07:28 -0400

From: Kiwi <kldawkin@undergrad.math.waterloo.edu>

To: bbc-list@ohm.york.ac.uk

Subject: Hi there

Hello.

I am supposed to say what hardware I have... right now, I have nothing. Zip. Zero. Bugger all. Not a sausage. Nada.

It's all back home in NZ. BUT, that doesn't mean I don't want to

be on the list.

In NZ I have a BBC B with 64KSWR, 400K drive, etc. A pretty

standard system.

If anyone wants any utilities written for them in 6502, I'd be

glad to have a crack at it... I haven't done it for a while

and I fear I might be rusty!

When I used my BBC I did a great deal of work with fonts (and co-wrote

a font editor for the BBC B which is far far better than anything available on the market. Right, Pat?) and music (I did tons of

music software and entered a great deal of music.

Cheers!

Kyle.


Re: Hi there
To: bbc-list@ohm.york.ac.uk

Subject: Re: Hi there

From: Pat Cain <cain_p@kosmos.wcc.govt.nz>

Date: Fri, 29 May 92 09:27:21 +1300

Organization: thesidewaysmachine, WCC City Net, Wellington, New Zealand

Kyle <kldawkin@undergrad.math.waterloo.edu> writes:

> When I used my BBC I did a great deal of work with fonts (and co-wrote > a font editor for the BBC B which is far far better than anything

> available on the market. Right, Pat?) and music (I did tons of

> music software and entered a great deal of music.

Kyle, glad to see you're on this list.  Yes, yes.. the font editor is pretty good, maybe we should post it on this list?  How many people

can uudecode and transfer stuff to the BBC?  Dave <terros@sideways>

has written an unzip for the BBC so we could even compress it.

/paet/


Re: Hi there1
Date: Fri, 29 May 1992 08:10:08 +1000

From: daniel@yoyo.cc.monash.edu.au (Daniel Bowen)

To: bbc-list@ohm.york.ac.uk

Subject: Re: Hi there

On May 29,  9:27am, Pat Cain wrote:

> Kyle, glad to see you're on this list.  Yes, yes.. the font editor is

> pretty good, maybe we should post it on this list?  How many people

> can uudecode and transfer stuff to the BBC?  Dave <terros@sideways>

> has written an unzip for the BBC so we could even compress it.

Sounds like a good idea to me. There's precious little software for Beeb's these days.. anything is better than nothing.

Daniel Bowen

--

Daniel Bowen, Monash University |

            Melbourne Australia |          POPE GETS GRIT IN MOUTH!

   daniel@yoyo.cc.monash.edu.au |

      TCWF: tcwf@gnu.ai.mit.edu |                                 [TCWF 78]


View
Date: Fri, 29 May 1992 08:16:10 +1000

From: daniel@yoyo.cc.monash.edu.au (Daniel Bowen)

To: bbc-list@ohm.york.ac.uk

Subject: View

While I have View version 2.1 in ROM on my Beeb, I usually load up (into SWR) something called View F2.1.  I don't know where I got it, and I've never heard of it officially, but it's got loads of extra highlight keys (such as italic, sub/superscript and stuff) and the cursor controls are better (for instance, CTRL-Left gets you to the start of a line, like on View 3). Though it doesn't have other stuff in View 3 like the NAME and MODE commands..

Does anyone know where the heck View F2.1 appeared from? Is it some sort of unreleased version from whoever wrote View (Colton?).. Just wondered.

Daniel Bowen

--

Daniel Bowen, Monash University |

            Melbourne Australia |          POPE GETS GRIT IN MOUTH!

   daniel@yoyo.cc.monash.edu.au |

      TCWF: tcwf@gnu.ai.mit.edu |                                 [TCWF 78]


Well...
Date: Thu, 28 May 1992 22:22:51 -0400

From: Kiwi <kldawkin@undergrad.math.waterloo.edu>

To: bbc-list@ohm.york.ac.uk

Subject: Well...

Pat suggested that the font editor be made public... that's fine by me except that I'll have to check it with Jonny (the other author) first. I'll get back to you with a final word. Perhaps Jonny will let you post some of his extraordinary fonts too... they are absolutely incredible.

The font editor takes all standard formats for fonts (the AMX ones being the main format) including Clares' Fontwise Plus format so you can print with them rather nicely if you have Fontwise Plus.

Pat, I'm sure you have tons of PD BBC software that could be distributed. The problem is that if there are only a few people reading the group, they won't get very far. If people still go to user groups (which I hope still exist!) then maybe that's a way to distribute the software freely.

Cheers.

Kyle.

PS. Pat - I'll be home in July.


'Posting' software
Date: Fri, 29 May 92 10:30:32 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: 'Posting' software

As a general rule I suspect sending out software using the standard mailing system shold perhaps be avoided. Many people have mail limits of some sort or other (including me) and if large things appear in mail boxes and this fills it or causes it to be full quite soon mail is normally lost FOREVER. This could cause a lot of annoyance.

I sugest the best way would be to perhaps either to use the newcastle mail server, which is Acorn only, or an ftp site for 8 bit only is created by someone with enought authority and disc space, ie not students!

Does everyone agree?

Richard.

:----------------------------------------------------------------------:

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     : :----------------------------------------------------------------------:


Re: 'Posting' software
Date: Fri, 29 May 92 12:31:49 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: 'Posting' software

>I sugest the best way would be to perhaps either to use the  >newcastle mail server, someone with enought

>authority and disc space, ie not students!

We should have more than enough disc space here (we're about to get  4Gig of extra space, betweeen about 6 people!). Stuff can be ftp'd to shiraz.ohm.york.ac. This assumes everyone has ftp access - I probably  won't be able to provide a mail server.

As for the format, it would porobably be best if the stuff is tar'd  and compressed, as this is pretty much the standard format for ftp  sites. Of course this means that you can't extract it on a bbc  (unless you know different), but I don't suppose anyone is going to be ftping dirrectly onto an 8-bit. Everything is goping to have to be  staged though a Unix/VMS(/Dos?) machine so there shouldn't be that  muchof a problem.

I've put a copy of tcc on there, and a list of all the people on the  list, with details of interests ad hardware.

Some decent font software would be excelent. The graphics explosion  was not forseen in the original Acorn vision of things, and support  for fonts (particularly getting more stuff on screen at once,  proportionaly spaced, in windows etc) was overlooked.

Ian


Re: 'Posting' software1
Date: Fri, 29 May 1992 12:32:26 GMT

From: Pat Cain <patrick@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: 'Posting' software1

I Stephenson <ian@ohm.york.ac.uk> wrote:

(> We should have more than enough disc space here (we're about to get

(> 4Gig of extra space, betweeen about 6 people!). Stuff can be ftp'd to

(> shiraz.ohm.york.ac. This assumes everyone has ftp access - I probably

(> won't be able to provide a mail server.

I'll put together a mail server in the near future, just got to write it.

(> As for the format, it would porobably be best if the stuff is tar'd

(> and compressed, as this is pretty much the standard format for ftp

Hmm.. but with quite a bit of Beeb software you need to retain the

load/exec addresses (mainly machine code stuff).  We've use BFM here on

Sideways ..

  BFM is a program several of us wrote so we could upload BBC programs

  to bulletin boards without having to worry about losing load/exec

  addresses or splitting up files.  The archiver/extractor for the BBC

  is written in basic and works on B, B+ and Master and is quite fast.

  We have already written an extractor in C for PCs which compiles okay

  under Unix.

ALSO, most Unix boxes have un/zip installed these days, so perhaps that

would be better for the compression part--that way people could extract

on Unix, PC or the beeb.

Re ftp: I usually ftp direct to PC disc and then chuck the disc into the

M512 and copy files over, or transfer files direct to the BBC via serial

link.  Thus bfm/zip would be a lot better for me.


posting software
Date: Fri, 29 May 92 16:45:48 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: posting software

the archiver written by I believe Gerben Vos (spelling?) maintains the load and execution adress by building a *exec file which sets the file attributes. I am guessing quite a bit here, but I thing it is suported in some way.

Since his archiver is pd why not use this?

Richard.

:----------------------------------------------------------------------:

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     : :----------------------------------------------------------------------:


re: posting software
Date: Fri, 29 May 92 12:45:31 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject: re: posting software

hi all,

The font's and comms software sounds great.

Only one slight problem I have no FTP access outside college since I am only a student but I have a reasonable mailbox so can anyone come up with an idea??

About View - I am afriad I have never heard of view F2.1 but I have a small program for a printer driver that is excellent and allows you to use all factilities of your printer like enlarged text, NLQ etc.

It is all user definable, I got it from an old issue of BBC ACORN USER,  soI do not know about the Copyrights!

Hope that is of some help,

Stephen.


Re: posting software1
Date: Sat, 30 May 92 15:39:14 BST

From: Tom Hughes <thughes@dcs.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: posting software

In reply to Richard York

>the archiver written by I believe Gerben Vos maintains the load and

>execution adress by building a *exec file which sets the file attributes. I am

>guessing quite a bit here, but I thing it is suported in some way.

>	Since his archiver is pd why not use this?

I have a copy of this, which is basically a cut down version of arc actually written by Bart Bruns, together with uuencode and decode. The only problem is that the archiving part of the software has a bug in it, so files often fail the CRC when unpacking. Gerben gives a workaround in the documentation (ading a few bytes to the file before packing it), but I found that with long files I had to add a lot of bytes (like several hundered) which is slightly annoying.

This may be fixed by now, I don't know. If it is fixed Gerben, then please tell me (and where I can get the fix).`

Tom.

============================================================================

Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road

cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


Re: posting software2
Date: Mon, 1 Jun 92 17:24:17 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: posting software

On Saturday May 30, 1992 Tom Hughes wrote in reply to Richard York:

>I have a copy of this, which is basically a cut down version of arc >(actually written by Bart Bruns, together with uuencode and decode.

>The only problem is that the archiving part of the software has a bug

>in it, so files often fail the CRC when unpacking.

And miss a bunch of bytes at the end.

>                                                   Gerben gives a >workaround in the documentation (ading a few bytes to the file before >packing it), but I found that with long files I had to add a lot of

>bytes (like several hundered) which is slightly annoying.

>This may be fixed by now, I don't know. If it is fixed Gerben, then

>please tell me (and where I can get the fix).`

No, it hasn't been fixed yet, to my knowledge. I have reported the bug, and Bart knows about it, but he doesn't have the time to fix it. It was probably hard enough to port Arc to assembler. I could try to obtain the source code from him, if anyone wants to try to fix it, but no guarantees...

BTW, that BFM (sp?) program sounds good. What does it do exactly? Does it only wrap the files with their addresses, or can it also compress them

(i don't think that's necessary, you can always compress or arc them afterwards)? Can it handle multiple files, or only one?

Greetings,

<>< Gerben.


ftp'ing to shiraz??
Date: Sat, 30 May 92 14:12:45 EST

From: Andrew Alf Leahy <A.Leahy@st.nepean.uws.edu.au>

To: bbc-list@ohm.york.ac.uk (beeb mailing list)

Subject: ftp'ing to shiraz??

> 4Gig of extra space, betweeen about 6 people!). Stuff can be ftp'd to

> shiraz.ohm.york.ac. This assumes everyone has ftp access - I probably

I've tried ftp'ing to shiraz.ohm.york.ac.uk (144.32.136.36) and it doesn't seem to work! Has anyone (outside of the UK) had any luck getting to this site?

> Some decent font software would be excelent. The graphics explosion

> was not forseen in the original Acorn vision of things, and support

> for fonts (particularly getting more stuff on screen at once,

> proportionaly spaced, in windows etc) was overlooked.

Speaking of grafix, I've written a program which I run on our Unix box to convert PPM images into BBC VDU code sequences...so I can display GIF's (what else!) on my beeb at home over the modem (using Termulator). Takes about a minute to display a Mode 2 screen, about 1 1/2 minutes for Mode 1 at 2400bps.

Question: Is there an Archie comms package which supports ye olde 8-bit

VDU codes? __________________________________________________________________________ Andrew "Alf" Leahy                                 phone: (047) 360671 (W) Uni. Western Sydney, Nepean.               fido: 3:713/601  irc: pepsi-alf Sydney, Australia.                  email: alf OR alf@st.nepean.uws.edu.au


Re: ftp'ing to shiraz??
Date: Mon, 1 Jun 92 8:55:37 BST

From: Thomas J Hughes <thughes@dcs.warwick.ac.uk>

To: A.Leahy@st.nepean.uws.edu.au (Andrew Alf Leahy)

Subject: Re: ftp'ing to shiraz??

In reply to Andrew Alf Leahy

>I've tried ftp'ing to shiraz.ohm.york.ac.uk (144.32.136.36) and it

>doesn't seem to work! Has anyone (outside of the UK) had any luck

>getting to this site?

I managed to get on once in the whole of last week. Doing a traceroute shows that the link fails between Manchester and York.

Tom.

============================================================================

Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road

cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


beeb SCSI interface card.
Date: Mon, 1 Jun 92 16:49:54 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: beeb SCSI interface card.

hi all,

just a note to say that anyone who is interested in the above needs to tell me fairly soon since I am having the boards made in my department and I break up for the summer on the 19th of June, so getting the boards is more awkward and also they will be increasing their prices at the end of the term so I want to get the boards I need made before then.

I have had quite a few expressions of interest but if you want one I want a FIRM statement to this effect. Since I make very little profit I can't afford to have anyone change their minds after I have built them. I hope everyone understands.

Below is a description for new group members;

****************************************************************************

A few questions have been made about what the SCSI interface card does.

Perhaps now is a good time to describe it a little more fully.

Firstly Acorn ADFS is 'hard wired' for SCSI device 0. It is easy to adjust so that is uses a different device, but the fixed device number remains. Currently multiple drives are supported using the LUN terminology. This system was chosen because in the days of the conception of ADFS SCSI drives were very rare. The system instead used SASI (a subset of SCSI, and infact what SCSI was based on) cards, which drove ST506 drives. This is how part of my system is built, although as I have said previously I now have a SyQuest drive connected direct to the host card, ie my SASI to ST506 card (Zebec 1410a for the record) is currently unused.

           Anyway these cards normally supported two drives (normally they had to be of the same type and size), and the LUN was used to select between them. Hense drive 0 is SCSI device 0, LUN 0, drive 1 is SCSI device 0, LUN 1 etc.

I have done some exploritary work on the ADFS with SOLIMON and have worked out the critical SCSI bus access code, so it COULD be possible to add support for multiple SCSI drives. However it would not be easy since;

a) ADFS 1.3 is TOTALLY full.

b) SCSI access code is duplicated in several places.

c) How is multiple drive support added? (probably converting LUN to device   number)

The question however must be asked; WHY whould you want more than one drive??

I certainly can't see any need for it. After all very cheap drives of around 20-40 Meg can be bould, which should be enough for any purpose I can think of.

Don't forget the drive can be partitioned for use with the Master 512, exactly like with the PC emulator on the Arc. The program is I believe provided with the 512, but I have a friend who has a program (published in Acorn User) which allows partitions to be created of arbitary size, which is much better than the Acorn offering.

The partition is simply a file of the required size created in the ADFS file structure, so it doesn't affect the normal ADFS operation at all.

TAPE STREAMER SUPPORT.

In principal it will work, in that the SCSI commands can be sent to the device, just as with a normal drive. However tape streamers use a slightly modified class of SCSI instructions which ADFS I don't think would be able to cope with. I suppose a piece of software could be written to create an ADFS filing system on the tape drive, but it would not be easy. Also the problem of 2 seperately addressable SCSI devices on the same bus would be a problem.

REMOVABLE HARD DRIVES.

These are obviously supported (I'm using one aren't I :-) ), but really this doesn't mean Acorn went out of their way to do it; just that they look exactly like a normal drive, except that certain commands respond slightly differently. For example issuing *BYE spins down the cartridge ready to eject it. I presume on a non-removable drive the particular command issued causes the SCSI drive to park its head, though I'm not sure.

Also I can issue a SCSI command to lock the cartridge and relase it, though I can't see any benefit in doing this.

GENERAL SCSI NOTES.

Osword &72 is effectively the "issue a SCSI command" OS call, and it works well. All the above calls (spin down drive etc) can be issued using this route, just as long as you know what command to issue :-) A SCSI standard helps!!!

Lots to chew over here. Basically its easy, and fairly foolproof. All you need is the host card, PSU, SCSI drive and something to put it in.

***************************************************************************

again replys before the middle of next week if possible please,

Richard York.

:----------------------------------------------------------------------:

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     : :----------------------------------------------------------------------:


Re: beeb SCSI interface card.
Date: Tue, 2 Jun 92 08:47:26 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: beeb SCSI interface card.

  Just a quick question...what is the PSU requirements of the card?

(basically, does it run from the drives supply or the micros)

thanks, Mik

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


No Subject2
Date: Mon, 1 Jun 92 23:54:56 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject:

Hi all,

in reply to Gerben Vos note on INKEY,

According to the manual(!), these are the extra value for INKEY

BBC Master 128K MOS 3.20   -    253

BBC Master Compact         -    245

Osbyte 0 (&00) should return the MOS number ie for the master 3.20 and a later number for the Compact.

Hope this is of some help,

Stephen.


Re: your mail
Date: Tue, 2 Jun 92 9:00:10 BST

From: Thomas J Hughes <thughes@dcs.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: your mail

In reply to Stephen McGuinness

>According to the manual(!), these are the extra value for INKEY

>

>BBC Master 128K MOS 3.20   -    253

>BBC Master Compact         -    245

>

>Osbyte 0 (&00) should return the MOS number ie for the master 3.20 and a later

>number for the Compact.

There is also an MOS3.21 (I think that's the number), although I don't think many machines were sold with it, and few people upgraded. The INKEY proably gives the same answer, but OSBYTE 0 may return a different code.

Tom.

============================================================================

Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road

cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


Re:
Date: Sat, 6 Jun 1992 03:10:34 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list <bbc-list@ohm.york.ac.uk>

Subject: Re:

smcgnnss@unix2.tcd.ie (Stephen McGuinness) writes:

> in reply to Gerben Vos note on INKEY,

>

> According to the manual(!), these are the extra value for INKEY

>

> BBC Master 128K MOS 3.20   -    253

> BBC Master Compact         -    245

For Arcs the values are:

Arthur        -  160

RISC OS 2.00  -  161

RISC OS 2.01  -  162

RISC OS 3.00  -  163

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


archivers
Date: Tue, 2 Jun 92 18:25:41 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: archivers

  I just obtained an archiver which seems to be pretty good - it's written in BASIC (although most of it is assembly code in actual fact). It retains the load/execute addresses of binary files (it actually BOOs binaries) and it seems to work (though I haven't tested it yet).

  I don't know whether this is what has been discussed on here already. I got it from the lancs.pdsoft archive...

  I'll test it tonight and let you know what I find out...

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


TequilaComm
Date: Wed, 03 Jun 92 01:51:20 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: TequilaComm

Alan Ralph <aralph@cix.clink.co.uk> writes:

>Perhaps we'd better make a list of who's produced what, what capabilities

>each program has so far, and compatability with various machines.

>

>So far I've counted yours and Dave's, plus the one I use, Gareth Babb's

>ATerm 0.79 (SWR version - also available in TTY and ANSI main-memory

>versions). Oh, and a 4-colour version of same, which has to be seen to be

>believed.

>

>All these can handle ANSI emulation and are at or working towards Ymodem

>transfer. Any others?

Well, mine goes something like this:

=== TequilaComm (1.2) ===

ansi/vt52 modes: ansi supports all of the vt102 codes as far as I am aware, and    some of the extras found in vt200+ (oh, 132 col mode isn't supported tho...)

Italics, inverse, underline all work. Flashing does not, italics are used instead.

Built in PC graphics font, which is the standard graphics character set used here at east...

X/Ymodem: This uses unbuffered file saves. The advantage of this is there is never any delay as the data is writte/read from file in a big block. The disadvantage is that at 9600+ baud, the disc interrupts start butting in on the serial interrupts, and the drive is constantly stopping and starting. None of this worried me, I run at 2400 and I preferred not waiting while a block loaded in, but eventually I will probably include an option for a buffered mode as it seems popular

the file transfers have an estimated time til finish clock, a time so far clock, and a %age transferred reading. CRC mode is supported of course.

Scrollback This is my favourite feature, and the real reason I wrote my program. scrollback takes as much sideways ram as you have to offer, on my mchine about 40k of scrollback ends up free. That's a lot of text! Also, quoting from scrollback and saving text from scrollback.

80 column, 40 column and teletext modes are supported. There is a mode 2 colour mode which operates in 80 columns, but is only for displaying colour Ansi screens, as the text is unreadable. 32, 25 and 24 row modes are all supported for 80 and 40 column modes.

That 4 colour mode you talked of sounds interesting...

All screen writes are direct write, very fast, but won't work on shadow ram.

All options are menu driven.

There is a dialling directory with auto login options, repeat and list dialling modes.

There is an online help system too, not context sensitive sorry.

The input buffer is 1k long, instead of 256 bytes. I inted making it longer still for master owners, but that's still to be done.

... and lots of neat extras, like anti-idle (avoids getting ogged off due to idle time), and saveable startup configuration.

The menu/dialling directory/file transfer overlays are stored in either

sideways ram or on disc, in order to workwith any system. Some of the more advanced options only work with sideays ram.

Oh, and there's a nice animated mode 7 title screen, which is interrupt driven, so runs whilst the rest of the program is loaded in. Don't you appreciate those little touches? :-)

The whole thing is written in assembly and took a bit over a year to get to what I thought was a releasable stage. it's taken a further 6 months so far and I still haven't managed to "release" it! BBC software distribution I am finding is not an easy thing to do!

=========

I want to release it as shareware, with a registerable version priced at $30 NZ. Uncompressed total size is 45k in a bfm archive.

In actual fact, a lot of the features listed above are not in the unregistered version, including the infamous Ymodem. The most obviously missing features are Ymodem, repeat/list dialling, and auto login feature.

A friend of mine is working on getting the shareware version onto shiraz.ohm.york.ac.uk

...it is on the actrix ftp site, bulletin board, but that's not much use to you outside new zealand...

Dave.


BFM
Date: Wed, 03 Jun 92 01:37:36 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: BFM

Gerben 'P' Vos <gpvos@cs.vu.nl> wrote:

>No, it hasn't been fixed yet, to my knowledge. I have reported the bug, and

>Bart knows about it, but he doesn't have the time to fix it. It was probably

>hard enough to port Arc to assembler. I could try to obtain the source code

>from him, if anyone wants to try to fix it, but no guarantees...

Was it actually written in assembler? I was disassembling it to try and find the ARC format (but gave up when I got the ZIP info instead). I'd swear it was compiled...

>BTW, that BFM (sp?) program sounds good. What does it do exactly? Does it

>only wrap the files with their addresses, or can it also compress them

>(i don't think that's necessary, you can always compress or arc them

>afterwards)? Can it handle multiple files, or only one?

BFM only stores the files, no compression. I have a text file of the format here somewhere, and there is a basic program that handles the format on a bbc...


Arc by Bart Bruns (was Re: BFM)
Date: Thu, 4 Jun 92 12:25:27 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Arc by Bart Bruns (was Re: BFM)

On Wednesday June 3, 1992 Dave Sainty <terros@sideways.welly.gen.nz> wrote:

>Was it actually written in assembler? I was disassembling it to try and find

>the ARC format (but gave up when I got the ZIP info instead). I'd swear it was

>compiled...

Maybe it is. I don't know for sure, but i remember disassembling part of it (to get it working on an Electron), and it looked a bit too mechanical, yes. Maybe then the bug got introduced by the compiler. That would make debugging even harder...

Greetings,

<>< Gerben.


Archivers1
Date: Wed, 3 Jun 92 13:03:17 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Archivers

  That archiver I mentioned is pretty good. I managed to successfully archive (and de-archive) Revs last night (one 6K file and a short BASIC prog).

  The only problem might be that there is no docs - it aint difficult tho'

  It stores files in ASCII format so binaries are BOOed first. this makes the archive rather larger than the source files but it can probably be compressed with a text compression routine (I'm not an expert here - someone like to comment?)

  all binary files (i.e. EVERYTHING other than pure ASCII) MUST be stored as binary (this includes BASIC programs) but it does retain the addresses and the entire filename (full path if required).

  It will work under any FS which supports direct file access (so sayeth the bit of text that IS supplied) so ADFS/NFS should be OK but I don't know how it would cope if you told it to store a directory - it might work actually, I'm not sure (I only tested it under DFS).

  Both programs (Archiver and Dearchiver) are written in BASIC.

  I will upload them to the ftp site (shiraz?) in a few minutes. Does anyone know of a PD text compression system that could be used to compress the final archives? (for that matter, does anyone know whether compressing them is a good idea?)

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Archiver
Date: Wed, 3 Jun 92 14:58:09 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Archiver

  I just uploaded the archiver and dearchiver to shiraz. I have put the instructions for extracting them in there as well. Can I suggest that you put them in some kind of sub-directory Ian because they are three seperate files and will become separated and lost if other people start uploading stuff.

  I hope they are useful

Mik

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: Archiver
Date: Wed, 3 Jun 92 15:13:25 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: "Mik Davis" <davism@uhura.aston.ac.uk>

Subject: Re: Archiver

I've moved the archiver stuff into a directory called "archiver"  (pretty obvious realy). Now all we need is for someone do upload some  REAL software :-)

There has been some hassle reaching shiraz by ftp - all I can suguest  is that you keep trying. It appears that the jips links are a little  flakey, but the ftp set up does work.

Reguarding compression - I don't realy think it's worth the hassle  (unless anyone has a realy brilliant solution). The files aren't

going to be that big, so size shouldn't be a problem.

Ian


Re: Re: Archiver
Date: Wed, 3 Jun 92 16:03:34 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: ian@ohm.york.ac.uk

Subject: Re: Re: Archiver

 >      I've moved the archiver stuff into a directory called "archiver"

 >      (pretty obvious realy). Now all we need is for someone do upload some

 >      REAL software :-)

 >

  I'll try and get some stuff up within the next few days. I have some PD stuff around

 >      There has been some hassle reaching shiraz by ftp - all I can suguest

 >      is that you keep trying. It appears that the jips links are a little

 >      flakey, but the ftp set up does work.

 >

  Yeah - I'll just have to keep trying

 >      Reguarding compression - I don't realy think it's worth the hassle

 >      (unless anyone has a realy brilliant solution). The files aren't

 >      going to be that big, so size shouldn't be a problem.

 >

  agreed, are we going to standardise onto this archiver then? - if so,

maybe you ought to say so on the list?

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Update my info on Shiraz - thanks
Date: Thu, 4 Jun 92 1:10:35 EST

From: Andrew Alf Leahy <A.Leahy@st.nepean.uws.edu.au>

To: bbc-list@ohm.york.ac.uk (beeb mailing list)

Subject: Update my info on Shiraz - thanks

I have some further info...which can be added to the "people" file on Shiraz (YES...I finally got thru! I grabbed those arc'ers too - will try them).

alf@st.nepean.uws.edu.au (Andrew Alf Leahy)

BBC Model B series 7, 128K SWRAM, 2x80T FD, Music 500 + 5000/87 s/w,

Music 2000 (MIDI) driving a Roland D-110 module, Speech, 9-Pin printer, 24-Pin colour printer, 8-pen colour plotter, Netcomm 24/24 Modem, lot's of s/w (we'll that's my opinion - but most of it's at least 5 yrs old!),  Apple MAC mouse converted to run like AMX Mouse (plus AMX Art/Pagemaker), Wico Trackball converted to look like AMX Mouse!, assorted hardware bits (lightpens, joysticks, speech processors, User Port "break-out" type box -  with flashing LEDs - wow!).

Ex-Software Librarian for OZBEEB the Sydney Acorn Users Group (it still exists - mainly Arc nowadays). I've had my Beeb since mid-1983, main interests are graphics/music. I mostly use it as a terminal for logging onto Uni., and some word-processing (using Interword - which I prefer over View).

I'm a final year student (hopefully) at Uni. Western Sydney, studying part-time Applied Science - Computing, and I work as full-time casual(!) SA for our DEC/Ultrix machines.

*phew* __________________________________________________________________________ Andrew "Alf" Leahy                                 phone: (047) 360671 (W) Uni. Western Sydney, Nepean.               fido: 3:713/601  irc: pepsi-alf Sydney, Australia.                  email: alf OR alf@st.nepean.uws.edu.au


ROM Extension boards
Date: Wed, 3 Jun 92 17:12:43 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: ROM Extension boards

  How easy would it be to build a ROM expansion board? i.e. a board to give me all 15 sockets available rather than just the 4 standard ones.

  I have an issue 7 BBC B

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Homebrew s/w RAM
Date: Wed, 3 Jun 92 17:11:05 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Homebrew s/w RAM

  A friend of mine wants to make a homebrew sideways RAM from a 62256 chip {available from Maplin.} Does anyone know where to get the write enable and rom select lines from? I have seen 62256s used in this configuration but don't recall how they were wired up ....

  Replies to STILESAJ@UK.AC.ASTON.VAX.SPOCK

             CBS%UK.AC.ASTON.VAX.SPOCK::STILESAJ if using VMS.

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


User Guides and hardware bits
Date: Thu, 4 Jun 92 15:24:14 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: User Guides and hardware bits

  I haven't got an Advanced User guide - does anyone know where I could get one. I asked my local library to try and find one but they gave me a copy of "The BBC Micro Advanced Reference Guide" which has a lot of stuff in but isn't quite as good.

  While I'm on the subject, I have a fantastic book (well I thought so) called "Inside the BBC Micro" which contains lists of all the routines and RAM usage for OS1.2, BASIC 1, BASIC 2, NFS(can't remember the version) and some tube stuff oh yes, and HIBASIC. I bought it for about 50p at an all formats fair last year. It's the same size/shape as the User Guide (and it is spiral bound in the same way too).

  Also, D.A. Gilbert told me the following about ROM expansion boards:

> there was a circuit in a VERY early (e.g.

> 1st or 2nd series I think) Micro User - just build

> that - it worked for us

  Does anyone have details of this?

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Archiver1
Date: Thu, 4 Jun 92 15:28:18 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Archiver

   The archiver CANNOT handle directories in any way. I just thought I'd mention that, I tested it last night. I think that it should be possible to write an archiver which handled directories correcly based on the techniques used in this piece of software but it would take some serious writing (from scratch).

   Maybe I will have a go sometime if I can get in touch with the original author and ask to use his routines.

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


No Subject3
Date: Thu, 4 Jun 92 23:17:25 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject:

Hi all,

Mik Davis was asking about the Advanced User Manual

well the version I have is as follows,

The New Advanced User Guide

by Dickens & Holmes

published by Adder Publishing Limited

at P.O. Box 148

   Cambridge

   CB1 2EQ

   England.

It covers everything from the Electron through to the Master and Compact.

A quick question:

Can you change the key code sent to the serial port under the Terminal program on the master because I can not use the cursor keys with Terminal because the host system does not understand them ( which makes editing a little difficult!)

Stephen.

smcgnnss@unix2.tcd.ie


Advanced user guide
Date: Fri, 5 Jun 92 08:50:56 BST

From: David Alan Gilbert <gilbertd@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Advanced user guide

Hi - Mik Davis was asking about the Advanced User Guide - I've got both the original Bray Dickens and Holmes one, and the Watford one for the Master. I have also seen the New Advanced User Guide - I dont like it - in actual fact I ordered it and sent it back.  The problem is that they put all the beeb, electron, master etc. stuff into around the same thickness which use to have just the beeb stuff in.  If you can find the original thats the one you want!

The Watford one is fairly bad - it seems to be lashed together between the old BBC Service manual,( to the point that there are a number of blatant mistakes - stating stuff which just isn't true anymore ) it has a few things about the extra banked ram in the master - that is useful.  IT has structures of one or two file types.

It has a lot of junk concerning the second processors, mainly the Z80 one - why I dont know because that was the only one which was never intended for internal Master fitting.

Its possible redeming feature is the Master Circuit diagram.

Dave

------------------------------------------------------------------------------- - David Alan Gilbert - gilbertd@p4.cs.man.ac.uk - G7FHJ@GB7NWP                - -------------------------------------------------------------------------------


Re: Advanced user guide
Date: Fri, 5 Jun 92 14:18:36 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Advanced user guide

 >      Hi - Mik Davis was asking about the Advanced User Guide - I've got both

 >      the original Bray Dickens and Holmes one, and the Watford one for the Master.

 >      I have also seen the New Advanced User Guide - I dont like it - in actual

 >      fact I ordered it and sent it back.  The problem is that they put all the

 >      beeb, electron, master etc. stuff into around the same thickness which

 >      use to have just the beeb stuff in.  If you can find the original

 >      thats the one you want!

 >

  I thought as much when I saw it in a shop - any ideas on where I might get an original version?

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Upgrade your Arc to a Beeb
Date: Fri, 5 Jun 92 11:56:59 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Upgrade your Arc to a Beeb

Hi people!

This sounds all very busy, so I thought I would join in...show my face.. whatever...I'll be brief, because I should be revising...honest!

I've got about, umm, 10 beebs (at last count...could be 11 or 12 now, I can't be sure :-)...), half of which are masters. Many extra goodies have been purchased over the years, and in case anyone else has one then here is a brief list:

- Opus Challenger 3 silicon disk systems

- 6502 2nd procs

- 32016 2nd procs (has anyone got PanOS1.2...1.1 is bad...and I need a copy            of an editor that actually works!)

- Teletext adapter

- Torch Graduate PC emulator (with 2 drives and 640k RAM)

- Music 500/5000 system

- IEEE488 adaptor (anyone got the software/ROMs?!)

- MicroRobotics EV1 camera

- Mouse/trackerball/touchpad/RTC/etc/etc/etc

My main interest is in telecommunications and bulletin boards. I run my own board, a viewdata system, called Challenger BBS. A friend (who will no doubt join the list next year) and I have developed some nice viewdata host software thats quite good at upsetting Arc owners (it goes faster than 38400baud, with a mouse controlled windows environment for the sysop, scrolling banners, etc.). I have quite a collection of modems that have accumulated over the years.

-------

Advanced user guides: I have one or two spare ones, of the type people seem to be looking for!

Mice: Anyone got a spare NV DigiMouse or AMX MkIII? I need one as my BBS now has a mouse permanently attached and I therefore don't have one for normal use :-(

InterBase ROM: Anyone got one? Are they any good?

-------

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Archiver (again!)
Date: Fri, 5 Jun 92 15:06:38 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Archiver (again!)

  I have started work on a new archiver which will handle all the things which have been mentioned so far, it will cope with directories and wildcard specified source names. The archive will be ASCII format suitable for distribution in almost any form (that I can think of).

  The de-archiver will be compatable with the files produced by the archiver I put on shiraz the other day.

  The only problem is that I have used several of the procedures from that package in the new version but I really need to get in touch with the author to ask whether this is OK.

  Does anyone know who "S. M. Goldthorpe aka the BeebBasher" is?? - I assume he is on the net somewhere as his package came from lancs.pdsoft originally (although this doesn't prove anything!).

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


For Sale ?
Date: Fri, 5 Jun 92 15:44:01 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: For Sale ?

I friend of a friend might know someone who may be selling a 32016  second processor if anyone is interested.

I've just got one of these myself - they're a bit of a pain to use  from floppy (at least for running Panos), but then hard discs will  abound pretty soon. At the very least they run BBC basic pretty well,  at 6 times the speed, with 995K free to basic! (in any screen mode  :-). They come with virtualy every language under the sun.

They're pertty rare beasts, but I'm currently trying to track down  users, so we may be able to get some sort of support going. If anyone  is interested in buying this one, then get in touch with me. The

price should be pretty much rock bottom.

Ian Stephenson


ZIP Arc/unarc
Date: Fri, 5 Jun 92 16:53:32 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: ZIP Arc/unarc

I know the original is written in fairly serious C, but I don't suppose anyone has done ZIP or unZIP for the beeb, by any remote chance?

Mik> I have some copies of the original advanced user guide!

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


BBC Archiver, Tequilacomm, Game
Date: Sat, 6 Jun 1992 02:55:16 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: BBC Archiver, Tequilacomm, Game

I have placed the BFM archiver on shiraz in *EXECable format, in the incoming software directory. I have also placed version 1.2u of Dave's comms package "Tequilacomm", which is archived using BFM, at his request.

A long time ago I saw a game for the BBC, which I think was a magazine game, which involved a space craft flying from left to right across a static mode 1 screen. It seemed to be set up so that there would be one enemy per screen. The types of enemies ranged from homing mines to missile bases and the like. A very simple little game.

Well I never had a copy of it, but thought it would be fun to write my own version, so I did. It will download itself to &E00 if it needs to (which it will on standard BBCs) but it is legally written, so it should work with shadow ram and second processors. It works fine under the BBC and Tube emulators on the Arc.

Would anyone be interested in seeing it on shiraz?

BTW This is my first posting to the mailing list... although I have not been told to, I understand from previous postings that I should say what hardware I have :-)

Well I used to use a BBC B with a 1770 DFS and ADFS, and a Solidisc 4 Meg 32k board. Now I have an A5000. But the BBC emulator plays a mean game of Starship Command...

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


zip & ram
Date: Sun, 07 Jun 92 04:17:40 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: zip & ram

From: "Mik Davis" <davism@uhura.aston.ac.uk>:

>  A friend of mine wants to make a homebrew sideways RAM from a 62256 chip

>  {available from Maplin.} Does anyone know where to get the write enable

>  and rom select lines from? I have seen 62256s used in this configuration

>  but don't recall how they were wired up ....

Yes, this is what I have done. The 62256 can be used as a 16k ram, but that would be silly. The first one I made took up two sockets of the 4 (no rom board), and had diodes stuck on it, but I'de improved on that....

Ok, the ~WE line I have taken from pin 8 on IC77. This is a 74LS00 in the top left corner of an issue 4 board. It should be consistant on other issues.

This needs to be run to pin 27 on the 62256's. You should probably bend this

pin up so it does not plug into the board...

That is all you need to do for 16k, but you have another 16k to play with...

IC76 houses the rom select latch, and pin12 off this chip (a 74LS163) should be connected to pin 1 on the 62256's (again, bend te pin up). I forget which line this is, but I think it is bit 2 of the 4 bit select register.

This means (if you plug the 62256 into socket 3), rom 3 and 11 map to one 16k bank, and rom 7 and 15 map to the second bank. Without using the rom select,

rom 3, 7, 11 and 15 all map to the single bank of ram.

>  Replies to STILESAJ@UK.AC.ASTON.VAX.SPOCK

I trust he'll get to read this...

==============

From: julian <julian@bridge.welly.gen.nz>

>I have placed the BFM archiver on shiraz in *EXECable format, in the

>incoming software direcory. I have also placed version 1.2u of Dave's

>comms package "Tequilacomm", which is archived using BFM, at his

>request.

Thanks Julian.

==============

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

>I know the original is written in fairly serious C, but I don't suppose

>anyone has done ZIP or unZIP for the beeb, by any remote chance?

I've written UNZIP. I intend to write ZIP. Do people want me to put what I

have done so far on shiraz?


zip
Date: Sat, 6 Jun 92 19:40:59 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: zip

>

> >I know the original is written in fairly serious C, but I don't suppose

> >anyone has done ZIP or unZIP for the beeb, by any remote chance?

>

> I've written UNZIP. I intend to write ZIP. Do people want me to put what I

> have done so far on shiraz?

>

Yes please! (As soon as I work out how to get stuff of it then I'll be using shiraz - anyone going to put a quick 'user guide' or something up?!)

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: shiraz
Date: Mon, 8 Jun 92 9:03:17 BST

From: Thomas J Hughes <thughes@dcs.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: shiraz

In-Reply-To: <9206061841.AA10416@hpb.lut.ac.uk>; from "RWF Whitehand" at Jun 6, 92 7:40 pm Comments: BBC Mailing List

Sender: bbc-list-request@ohm.york.ac.uk

In reply to RWF Whitehand

>Yes please! (As soon as I work out how to get stuff of it then I'll be using

>shiraz - anyone going to put a quick 'user guide' or something up?!)

As far as I can make out, the problem is not with shiraz itself, but

with the Janet JIPS links to it. In particular, my attempts to connect

get stuck at Mamchester, and can't make it across the Pennines to

York. I did get on once about 10 days ago, but have had no luck since

then.

Tom.

============================================================================

Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road

cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


SW RAM wiring
Date: Sat, 6 Jun 92 19:50:55 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: SW RAM wiring

Forwarded from my Co-SysOp (Martin Ebourne), hope it is of use!:-

>

>     Yes, I do use a 62256 (or any one of a number of variants of it). The pins

> to use are in your Beeb at home. Anyhow, specially for him (hope he

> appreciates this!) I shall work them out....[Hang on a few mins...]

>

>     Right. Here we are. For 16k, just take pin 27 (notWE) to the Beeb R/notW

> or notWDS line anywhere. I tend to use IC73 (A>D chip, 7002) pin 24 (5th down

> on right) because it is a big chip which it is easy to find! If he wants two

> banks (32k), ie. has a brain cell, then for non-ROM board compatibility taking

> up only one socket, take pin 1 (A14) to a random pin on IC76. (Little one, SW

> corner.) I particularly recommend pins 11 or 12 since then it stands a chance

> of working! (If it doesn't, then it ain't my fault - honest!) If he has a ROM

> board, then it will need 2 slots. Put the RAM in one, & take A14 to the notCS

> pin of the other. Obviously the pins which are wired to somewhere else need to

> be non-inserted into the socket. It is advisable to butcher an IC socket and

> put the RAM in it. (Not that I always do!)

>

>     Of course, if has has a ROM board, it might not work. Depends on the type.

> The cheapo watford thing works with the last technique, as most prob. will,

> but ones which add lots of RAM & take control (ie. sensible) don't work at

> all. (eg. Soli 256, poss. watford ROM/RAM card thingy - that is a rip-off of

> the Soli board, and a bad one at that!) All other pins, of course, go to the

> respective ones in the socket.

>

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Defender
Date: Sun, 7 Jun 92 01:40:33 BST

From: Jason O'Broin <J.P.O'Broin@durham.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Defender

A long long time ago, when I was first starting to use the Beeb (so this must have been 83/84), I saw an internal Acorn version of Defender that was hugely configurable (whoops, I mean Planetoid!!). I don't remember much about it, but I would be interested to know if

a. anybody has a copy of this.

b. Any other details.

Jason

[Side note: IBM Disk Reader

 Well, I blame it on exams really.

 Nothing to do with me at all. Probably the weather.

 After all, what's a *SPOOL between friends?

 Yes, I appreciate I meant *EXEC...

Okay, I'll come clean. I found a copy of my IBM Disk Reader on an Arc  disk the other day but I managed to delete the machine code source while  trying to assemble it.

Sorry

So, you'll all have to wait until I go home (next week) before I can pick up another copy of it.

I didn't mean it. Nothing personal ... :-(


Defender1
Date: Sun, 7 Jun 92 13:10:37 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Defender

>

> A long long time ago, when I was first starting to use the Beeb (so this

> must have been 83/84), I saw an internal Acorn version of Defender that

> was hugely configurable (whoops, I mean Planetoid!!). I don't remember

> much about it, but I would be interested to know if

>

> a. anybody has a copy of this.

> b. Any other details.

>

> Jason

I have a copy of something called 'Modified Defender' which looks a little different, and I *THINK* you might be able to configure all sorts of things (its along time since I last played with it!).

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


ram
Date: Mon, 08 Jun 92 21:23:32 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: ram

> up only one socket, take pin 1 (A14) to a random pin on IC76. (Little one, SW > corner.) I particularly recommend pins 11 or 12 since then it stands a chance > of working! (If it doesn't, then it ain't my fault - honest!) If he has a ROM > board, then it will need 2 slots. Put the RAM in one, & take A14 to the notCS > pin of the other. Obviously the pins which are wired to somewhere else need

> to be non-inserted into the socket.

This second method will not work, as the chip is not being selected for the second bank. But, all is not lost.

If you want to use this method, run a ~10k resistor from +5v to the chips

notCS. you will need to put a diode between socket 1 notCS and the chip, and also A14 and chip notCS. The line from A14 goes to socket 2.

as usual I can't remember which is anode and which is cathode... but both are wired as so...

chip       |` |        one to A14, one to the socket notCS.

notCS------| >|-------     the socket one is tricky, I suggest you use a DIL

           |/ |            socket, to protect both the chip and the on board

                           socket...

This was my "mark II" sideways ram, before I found out where the rom latch

was. "Mark I" was a beauty! two 8k chips soldered on top of each other, with a 74LS04 sellotaped upside down on top! Looked a real mess, but do it with 2 32k chips, and you'd have a single 64k module, very nice!


Manuals
Date: Tue, 9 Jun 92 09:34:30 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: Manuals

Hi,

I have just upgraded from an 8271 to a 1772, and have therefore changed from DFS to 1770 DFS & ADFS.

Does anyone have any manuals for 1770 DFS? There are one or two commands in there I don't recognise, and it doesn't seem to like my old 40T 8271 disks unless I twist its arm.

What is "SRAM 1.05"?

Does anyone have an ADFS manual?

Yours, Matthew

matthew_sweet@tadtec.uucp


Manuals1
Date: Tue, 9 Jun 92 10:54:43 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Manuals

> Does anyone have any manuals for 1770 DFS? There are one or two

> commands in there I don't recognise, and it doesn't seem to like

> my old 40T 8271 disks unless I twist its arm.

Erm, nope! Which commands are they? (I think it has format and verify in there and others that are probably fairly easy to guess the operation of...) Z-break or something like that (anyone remember? I don't use it much...) will put you into an '8271' compat. mode. However, this is just for games and things that like to have a go at protecting stuff (some won't work at all under 1770), you should be able to cat and use disks in the usual mannner quite normally under 1770...What are you having to do?

>

> What is "SRAM 1.05"?

As there was room in the 16k 1770 DFS ROM, Acorn decided to put sideways ram utilities (load/save/etc/etc) in it. Its really an addition to the OS, as per the Master.

>

> Does anyone have an ADFS manual?

>

Not into ADFS personally...well...not much...sorry, can't help there!

> Yours, Matthew

>

> matthew_sweet@tadtec.uucp

>

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: Manuals
Date: Tue, 9 Jun 92 14:42:50 BST

From: Tom Hughes <thughes@dcs.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: Manuals

In reply to Matthew Sweet

>I have just upgraded from an 8271 to a 1772, and have therefore

>changed from DFS to 1770 DFS & ADFS.

Which version of the old DFS were you using?

>Does anyone have any manuals for 1770 DFS? There are one or two

>commands in there I don't recognise, and it doesn't seem to like

>my old 40T 8271 disks unless I twist its arm.

As someone else has said, it has *FORMAT and *VERIFY in ROM (for DFS).

If you had an old 8271 DFS with *ENABLE, then this is no longer used,

as *BACKUP, *DESTROY etc now ask for a yes/no reponse before doing

their stuff.

>What is "SRAM 1.05"?

Already answered.

>Does anyone have an ADFS manual?

Is there such a thing? The master reference manuals provide some info

about the OS level interface (*commands, osbytes, etc). You probably

still need a utils disc to do format and verify under ADFS (although I

think the newest chipos may have these built in).

Hop this helps, Tom.

============================================================================

Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road

cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


Re: Manuals1
Date: Tue, 9 Jun 92 16:29:30 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Manuals

> As someone else has said, it has *FORMAT and *VERIFY in ROM (for DFS).

> If you had an old 8271 DFS with *ENABLE, then this is no longer used,

> as *BACKUP, *DESTROY etc now ask for a yes/no reponse before doing

> their stuff.

>

The last version of the DFS for the 8271 (DNFS1.2) used y/n prompts for

BACKUP, DESTROY, etc, if you didn't use ENABLE...ENABLE just means you

won't get the y/n prompt...it'll just get on with it...

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: Manuals2
Date: Tue, 9 Jun 92 14:57:08 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: Manuals

>Does anyone have an ADFS manual?

I've got a copy of a hard disc manual, which basicaly is an ADFS  manual. I don't have a hard disc (yet) but I aquired it with a whole  load of other stuff. It describes a number of new commands. I can't  remember what most of them are, but I can look them up. They deal  with such things as mounting discs, making directories and other  sundries.

I'll see what I can sort out as reguards circulating the information.

Ian


ADFS
Date: Tue, 9 Jun 92 16:46:59 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: ADFS

  Could someone please tell me what the latest version of ADFS that I can put in a model B is please...

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


ADFS1
Date: Tue, 9 Jun 92 21:28:39 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: ADFS

  Does anyone know where Acorn ADFS puts PAGE?

Thanks

--------------------------------------------------------------------------- |         Michael Davis           |   If you can keep your head when all  | |    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: ADFS
Date: Tue, 9 Jun 92 22:58:59 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: ADFS

On Tuesday June 9, 1992 Mik Davis <davism@uhura.aston.ac.uk> wrote:

>  Does anyone know where Acorn ADFS puts PAGE?

On an Electron it's &1D00. There are also packages for the Electron (Solidisk?) with an ADFS which uses some kind of on-board shadow memory to keep PAGE at &E00.

Greetings,

<>< Gerben.


Re:  ADFS1
Date: Wed, 10 Jun 92 14:57:39 +0100

From: Kieran L Turner <kierant@central.susx.ac.uk>

To: bbc-list@ohm.york.ac.uk, davism@uhura.aston.ac.uk

Subject: Re:  ADFS

MichaelD > Does anyone know where Acorn ADFS puts PAGE?

&A00 on a model B, from memory.

:-) Kieran


Re:  ADFS2
Date: Wed, 10 Jun 92 16:27:12 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re:  ADFS

> MichaelD > Does anyone know where Acorn ADFS puts PAGE?

>

> &A00 on a model B, from memory.

>

> :-) Kieran

>

Erk! That would be quite impressive! Well below page for a non-DFS or ADFS machine...infact I think the OS might complain a little.

ADFS (Acorn) is probably around 1F00 (ish), although, as with the Electron, the Solidisk things (which used to go in for a bit of agreement between DFS and ADFS on workspace, or something) reduced this a little. Bung Econet in and of course it wacks it up again, etc.

Regards,

Richard.

P.S. I don't actually have a Beeb with ADFS...even though I have 5 of 'em

     and 5 masters!...so I can't be sure about any of this!


Re: ADFS3
Date: Thu, 11 Jun 92 16:39:52 +0100

From: Kieran L Turner <kierant@central.susx.ac.uk>

To: R.W.F.Whitehand1@lut.ac.uk, bbc-list@ohm.york.ac.uk

Subject: Re: ADFS

Me (in a fit) > &A00 on a model B, from memory.

Richard       > Erk! That would be quite impressive!

True. What I meant was, of course, &1A00, which is what my BBC gets.

Kieran


Re: ADFS4
Date: Thu, 11 Jun 92 18:01:11 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: Re: ADFS

On Thursday June 11, 1992 Kieran L Turner <kierant@central.susx.ac.uk> wrote:

>True. What I meant was, of course, &1A00, which is what my BBC gets.

That's a bit unexpected. I thought there were no fundamental differences, other than the handling of the hardware, between the Electron and Beeb ADFS.

Maybe Acorn got too many complaints from Electron users about the large

amount of memory eaten by ADFS, and changed that for the BBC version?

Greetings,

<>< Gerben.


Re: ADFS5
Date: Thu, 11 Jun 92 23:23:08 +0100

From: Kieran L Turner <kierant@central.susx.ac.uk>

To: bbc-list@ohm.york.ac.uk, gpvos@nl.vu.cs

Subject: Re: ADFS

Gerben > > True. What I meant was, of course, &1A00, which is what my BBC gets.

Gerben > That's a bit unexpected.  [etc]

Well, I must add I suppose that my Beeb is usually a bit odd (it likes to

be different ;-) and the ADFS chip is in a ROM/RAM card.

-- K


ADFS and PAGE
Date: Wed, 10 Jun 92 16:10:13 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: ADFS and PAGE

MichaelD > Does anyone know where Acorn ADFS puts PAGE?

Kieran   > &A00 on a model B, from memory.

OK so you put a smiley there. However I am currently having hassles with this and it isn't funny. This Monday I upgraded my BBC from an 8271 with an Acorn DFS (page at &1900), to a 1772 with 1770 DFS and ADFS. Page is now at &1F00. I shall look tonight in the relevant area of memory for how much of this is private work-space, and how much is due to the 1770 DFS or the ADFS increasing the amount of global work-space, as this is the complete information required for you to be able to answer the question for your system.

For those who don't know, but who are interested, this is how I remember this working:

After RESET:

Each ROM is in turn asked how much global space it requires. The global space is set to the maximum amount requested. Each ROM is in turn asked how much private space it requires, and this is allocated above the global space. Page is then set to point higher than the allocated private space.

Unfortunately quite a lot of my S/W that relocates stuff to &E00 after selecting the tape filing system assumes page=&1900, and I am now attempting to put this right. (In a fully relocateable manner).

This change has also scuppered my copy of Wordwise-Plus, which I was planning to use to turn disassembled stuff that the change broke back into source so that I could re-assemble it after making the changes to stop such upsets in the future. Most irritating.

Micheal, have I answered your origional question, or are you not going to have 1770 DFS present as well?

Matthew

matthew_sweet@tadtec.uucp


Re: ADFS and PAGE
Date: Wed, 10 Jun 92 18:51:35 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: ADFS and PAGE

Thankyou for all the people who have replied about ADFS and PAGE. It turned out that the problem I was having was not being caused by the ADFS I was using but by the screen mode (PAGE at &1F00 and MODE 3 does not go well)

I think I must have been asleep at the time not to realise that MODE 3 grabs nearly 20K of RAM.

Thanks again ---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


ADFS and rom memory claim
Date: Sun, 14 Jun 92 19:54:16 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: ADFS and rom memory claim

MichaelD > Does anyone know where Acorn ADFS puts PAGE?

Kieran   > &1A00 on a model B, from memory.

I can't speak from experience as I don't have ADFS, but here's some figures

from the new advanced users guide.

        private     absolute

DFS     9           2

ADFS    6           1

This means that for a machine with both systems, you loose 9+6+2=17 pages (page at &1F00)

That ties in with what others have said. But what people aren't noticing is that if you keep DFS in your machine, you're going to loose DFS's horrific 10 extra pages, whether you use DFS or not...

By JUST having ADFS instead, you will only loose 7 pages, leaving PAGE at &1500. Isn't that a nice civilised location! Much better than &1F00 or even &1900! The best thing to do in my opinion is to use DFS in sideways ram when required, and have just ADFS in permanantly.


Re. ADFS6
Date: Thu, 11 Jun 92 20:09:49 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject: Re. ADFS

Hi,

The Master I have leaves the Page at &E00 while you are using ADFS but I

think this is caused by the adfs using extra special Ram for it's own use only,

Would I be right or is master ADFS different from the others?

Stephen.


CFV: comp.sys.acorn reorganization
Date: Tue, 9 Jun 92 22:31:24 MET DST

From: Gerben 'P' Vos <gpvos@cs.vu.nl>

To: The BBC Mailing List <bbc-list@ohm.york.ac.uk>

Subject: CFV: comp.sys.acorn reorganization

[Most of you will have seen this already on the News, but anyway...

Keep in mind that you reply to me, not to the mailing list, and please keep

the keyword "CFV" in the header, to make automatic processing easier for me. Thank you, and happy voting! -- <>< Gerben.]

It's

THE GREAT COMP.SYS.ACORN REORGANISATION

Hello, and welcome. Here are our contestants:

1) CREATE comp.sys.acorn.advocacy

   Description: Why my Acorn computer or program is better than yours. Or not.

   Charter: Here you can hold long debates why the ARM610 is better than the

   586, why Translator's user interface is so very bad (or good!), or why

   Acorn should lower their prices. If you hold your wars here, the people who

   want to actually *do* things can get on with their work in the other Acorn

   groups.

2) CREATE comp.sys.acorn.announce moderated Alan Glover <aglover@acorn.co.uk>

   Description: Announcements of interest to Acorn and ARM users. (Moderated)

   Charter: This will be a low-noise group in which announcements about

   (products for) Acorn computers or the ARM can be made, as well as

   additions to public archives, FAQ lists, virus alerts etc.

3) CREATE comp.sys.acorn.tech

   Description: Programming aspects and hardware of Acorn and ARM products.

   Charter: This group is for discussion among people who develop hard- and

   software for or with Acorn computers or ARM chips. Non-technical

   discussions belong in comp.sys.acorn.misc (or comp.sys.acorn, if .misc

   is not created).

4) RENAME comp.sys.acorn TO comp.sys.acorn.misc

   Description: The Acorn computer.

   Charter: This group is for discussion among users of Acorn computers.

   General Q&A belong here, as well as everything that doesn't fall under

   one of the other acorn groups. Lengthy discussions on the merits of one

   computer or piece of software over the other should move to .advocacy .

If you want to vote, please reply to this article (including its body), remove everything except the ballot below, and replace the X's by Y (Yes), N (No) or

A (Abstain), depending on your choice.

============================ BALLOT ============================

   vote-01: [X] Create comp.sys.acorn.advocacy

   vote-02: [X] Create comp.sys.acorn.announce moderated

   vote-03: [X] Create comp.sys.acorn.tech

   vote-04: [X] Rename comp.sys.acorn to comp.sys.acorn.misc ================================================================

The voting address is gpvos@cs.vu.nl, and voting is open from now until Friday 10 July 1992, 23:59:59 GMT. Yes, this is long, but during the last week of the vote i will be on holiday, so i'll return just in time to count the votes.

You are encouraged to vote before 3 July, so i can ask you for information if your vote is unclear in some way.

Please keep the keyword "CFV" in the subject header, that makes it easier for

me to separate the votes from the normal mail.

Voters will receive an automagic acknowledgement of their vote (unless my

vote processing script would break down, of course).

Unless i'm in a bad mood, i will also accept votes in a different format (as long as they are unambiguous and unconditional, i.e. "Yes, if..." type votes will be treated as comments and not counted).

Voting "AAAA" is the same as not sending any vote, except that you get your

name listed in the list of the results.

If you change your mind, you can send your new vote to me in the same way.

The vote with the last date stamp will count.

A proposal passes if it has 100 more yes than no votes, and there are at least twice as many yes as no votes for it. The four votes are separate, with the logical exception that if all of 1..3 fail, 4 (rename to .misc) will not be executed, even if it passes.

Thank you. May the best newsgroups win! (round of applause, commercial break)

. . . . . . . . . . . . . . . . . . . . . . . . . . . G e r b e n   V o s   <>< Aconet: 8500/104!Gerben Vos  Internet: gpvos@cs.vu.nl

Contrary to popular belief, the programmers at Acorn do know what they are doing.  -- Nicko van Someren


Screen memory
Date: Fri, 12 Jun 1992 02:46:20 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Screen memory

"Mik Davis" <davism@uhura.aston.ac.uk> writes:

> I think I must have been asleep at the time not to realise that MODE 3

> grabs nearly 20K of RAM.

Which reminds me... how many of you out there realised that there is some hidden memory *after* the screen memory and *before* the ROM starts, in modes 3, 6 and 7? I haven't seen this in a magazine before, and I don't believe it is documented as such in the Advanced User Guide.

Mode 7 is allocated exactly 1024 bytes for display but needs only 1000 at a time (ie. 40*25 characters), so there are 24 bytes free from &7FE8-&7FFF.

Mode 6 is allocated exactly 8192 (8k) bytes but needs only 8000 at a time (40*8*25) resulting in 192 free bytes from &7F40-&7FFF.

Similarly, mode 3 gets 16384 bytes but needs only 16000... 384 bytes are unused between &7E80-&7FFF.

It is important to remember that all this changes as soon as you scroll the screen in hardware, or clear it. If you want to keep the memory safe for use by a program, the easiest thing to do is to make the screen software-scrolled, by defining a text window with the screen's dimensions.

eg. for Mode 7,

VDU 28,0,24,39,0

would protect the memory. Unfortunately this makes scrolling a lot slower, especially in mode 3. But then again you may be writing a program that doesn't need to scroll the screen, such as an arcade game...

Anyone else found any other pockets of unused RAM hidden away on their machine?

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


Re: Screen memory
Date: Fri, 12 Jun 92 08:44:34 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Screen memory

 >      "Mik Davis" <davism@uhura.aston.ac.uk> writes:

 >

 >      > I think I must have been asleep at the time not to realise that MODE 3

 >      > grabs nearly 20K of RAM.

 >

 >      Which reminds me... how many of you out there realised that there is some

 >      hidden memory *after* the screen memory and *before* the ROM starts, in

 >      modes 3, 6 and 7? I haven't seen this in a magazine before, and I don't

 >      believe it is documented as such in the Advanced User Guide.

 >

 >      Mode 7 is allocated exactly 1024 bytes for display but needs only 1000

 >      at a time (ie. 40*25 characters), so there are 24 bytes free from

 >      &7FE8-&7FFF.

 >

  I thought that mode 7 used those 24 bytes. Didnt Richard (challenger) mention this on Monochrome?

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: Screen memory1
Date: Fri, 12 Jun 92 9:27:30 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Screen memory

>  >

>  >      Which reminds me... how many of you out there realised that there is some

>  >      hidden memory *after* the screen memory and *before* the ROM starts, in

>  >      modes 3, 6 and 7? I haven't seen this in a magazine before, and I don't

>  >      believe it is documented as such in the Advanced User Guide.

>  >

>  >      Mode 7 is allocated exactly 1024 bytes for display but needs only 1000

>  >      at a time (ie. 40*25 characters), so there are 24 bytes free from

>  >      &7FE8-&7FFF.

>  >

>

>   I thought that mode 7 used those 24 bytes. Didnt Richard (challenger) mention

> this on Monochrome?

>

Erm, it won't be used if you use software scrolly, etc. as he suggests later on in his message...however, I'm not into arcade games in Mode 7 :-) Its use is a little restricted...esp. as it probably gets cleared after a CLS (quicker for the OS to clear in sensible junks, I'm sure) and is 'miles' away from other useful RAM, etc. anyway.

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: Screen memory2
Date: Sun, 14 Jun 1992 18:48:59 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Screen memory

RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk> writes:

> Erm, it won't be used if you use software scrolly, etc. as he suggests

> later on in his message...however, I'm not into arcade games in Mode 7 :-)

I think that's a pity. In mode 7 you have the potential for *very* large sprites moving around quickly. You also have heaps of memory left over to make a much more involved arcade game than has ever been seen before on a 32k machine. Certainly there are complications with the use of colour, but it's not an insoluble problem, and even lack of colour never stopped games like Starship Command, Plan B and Aviator from becoming popular...

> Its use is a little restricted...esp. as it probably gets cleared after a

> CLS (quicker for the OS to clear in sensible junks, I'm sure) and is

> 'miles' away from other useful RAM, etc. anyway.

In 6502 code it doesn't matter where the ram is in relation to your code, you can still reference it with a single instruction. Also one of the reasons I brought it up was because someone mentioned getting their programs to work/download properly from ADFS, and in at least one case the only way I was able get get a program to work from ADFS was to put the download routine in that memory (I think, or it might have been the Basic stack). The program was loaded at PAGE and corrupted about 90% of the mode 7 screen... there was virtually nowhere else to put the download code!

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


Re: Screen memory3
Date: Fri, 12 Jun 92 09:43:38 BST

From: David Alan Gilbert <gilbertd@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Screen memory

>  I thought that mode 7 used those 24 bytes. Didnt Richard (challenger) mention

> this on Monochrome?

>

>

I did at one time manage to fudge an extra screen line in mode 7 in my Master 128 - but I couldnt get a full extra line - I suspect I only got the extra 24 bytes.  They exist and I dont think they are used for anything.

Dave -------------------------------------------------------------------------------

- David Alan Gilbert - gilbertd@p4.cs.man.ac.uk - G7FHJ@GB7NWP                - -------------------------------------------------------------------------------


Memory
Date: Fri, 12 Jun 1992 03:13:48 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Memory

RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk> writes:

> Erk! That would be quite impressive! Well below page for a non-DFS or ADFS

> machine...infact I think the OS might complain a little.

Not unless your Basic program was too large. In fact you can safely put PAGE down as far as &900, and have 1k in which to store your program and all it's variables, if you are willing to forego:

  Page &9 - Envelopes 5-16/Serial Output,Speech/Cassette output

  Page &A - Serial Input/Cassette input

  Page &B - Function key definitions (Use OSBYTEs 225-228 to disable theFN keys or use them for ordinary character codes)

  Page &C - Character definitions for CHR$224 - CHR$255

Page &D is used by the Disc and Econet systems (and anything else which needs NMIs) not to mention the extended vectors and Rom workspace bytes, so this cannot be used.

Pages &9 and &A can be used even if you are using the cassette system for whole file operations... they are only used when you are using BPUT, BGET, and OSGBPB on cassette files.

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


Memory1
Date: Fri, 12 Jun 92 9:21:51 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Memory

> > Erk! That would be quite impressive! Well below page for a non-DFS or ADFS

> > machine...infact I think the OS might complain a little.

>

> Not unless your Basic program was too large. In fact you can safely put

> PAGE down as far as &900, and have 1k in which to store your program and

> all it's variables, if you are willing to forego:

>   Page &9 - Envelopes 5-16/Serial Output,Speech/Cassette output

>   Page &A - Serial Input/Cassette input

>   Page &B - Function key definitions (Use OSBYTEs 225-228 to disable the

>             FN keys or use them for ordinary character codes)

>   Page &C - Character definitions for CHR$224 - CHR$255

>

> Page &D is used by the Disc and Econet systems (and anything else which

> needs NMIs) not to mention the extended vectors and Rom workspace bytes,

> so this cannot be used.

My average BASIC program uses >1k and the serial port unfortunately, probably the fnkeys too :-(

Anyhow, 'Challenger Host' has a re-written OS, so anything under &E00 has been re-arranged and used much more efficently anyway :-)

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


SWR
Date: Fri, 12 Jun 92 9:40:22 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: SWR

[Extracted from a large message from Martin Ebourne, Challenger's co-sysop]

>

>     Re: The S-RAM problem (You can quote this if you like):

>

>     Yes, you are quite right about the notCS and the diode arrangement. It

> must have been late at night, I wasn't thinking! I did precisely the same as

> that, only I used a 1M resistor. Thanks for pointing it out. I have actually

> tried both my RAM designs (the 2 socket one was my first before I found the

> rom latch as well, although I did have a ROM board then so I couldn't have

> used it anyway), and they both work perfectly (when wired correctly!). It is

> also fairly easy to wire a switch or two for read/write protect.

>

>     Something I didn't try, but was thinking about, was battery backup. That

> wouldn't be hard if you had one of the low voltage-current standby RAMs which

> could run on 3V. All you would need is a couple of diodes to the Vcc pin

> (probably germanium for low voltage drop), a couple of Duracell and there you

> have an instant battery backup! I'm not sure whether you would get any

> corruption in the ram on power up/down, but you may be able to wire the notWE

> line into the battery as well, which would protect it. If anyone's

> adventurous, I would be interested to know! Read protect it definately a good

> idea with battery backup though, in case of corruption.

>

>     I now have a Solidisk 256k board which can take 32k EPROMS with a special

> ROM store facility to select them. In attempt to save having to by 32k EPROMS,

> I soldered my collection into about 5-6 pairs, each with an EPROM directly on

> top of another, and the chip select lines taken away to the board.

> Unfortunately, they were all NMOS, and so consequently they got extremely hot

> in use (since there was no air flow around the bottom one). I had to abandon

> that idea, and very few of them survived the desoldering and chip select pin

> bending back process. RIP. I now have quite a few 32k EPROMS!!

>

>     Right. You can stop quoting now!!!

>

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Acorn Atom Found
Date: Mon, 15 Jun 92 14:30:13 BST

From: yorkr@p4.cs.man.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: Acorn Atom Found

While perusing piles of junk on Sunday afternoon (as one does) I came across a slightly soiled and sorriful little atom. No not something from the table of elements but an early Acorn, you know one of those that never grew into a tree :-) Can anyone help with a little info on this little 'seed' since it has a slightly fried regulator and it is a little 'tacky' inside (supersolve - what that?).

It seems to have 12K of RAM, a 4K eprom with 'atom toolkit' written on it. The 'expansion port' is not fitted (what went on it?) and the board is an issue 4. And the price I here you all ask???? Well to me 5 pounds. A bargain at half the price!

All help, as per usual, is gratefully received,

Richard.

PS this is remarkably the same as something I have just bunged on

comp.sys.acorn (OK a straight copy) but I thought after all it DOES have a 6502 in it!


UnZip
Date: Tue, 16 Jun 92 01:55:21 +1200

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: UnZip

I have just developed an new archiving system, which allows programs to "Auto extract". The archive file is in the format of an *EXEC file, you simply *EXEC the archive, and it takes over, retaining all load/exec addresses, and CRC checking the programs too, to ensure the archive is not corrupted.

It is not compressing, because I only actually wrote it with the intention of uploading UnZip to shiraz in that format, but as Zip is unavaliable so far, I think I'll upload these programs too (it adds about &170 bytes to the total size of all the files).

It may take a while to get them there as I have no direct link to shiraz. Julian, willing to upload some more stuff for me?

Dave.


Holiday mailings
Date: Thu, 18 Jun 92 16:03:18 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Holiday mailings

I presume a lot of group members will be disapearing off home for the summer soon, or have even gone already. I will still be around a fair bit over the summer months, so at least I will be reading! Will there be anyone else? 	Richard.

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     :


Re: Holiday mailings
Date: Thu, 18 Jun 92 17:24:51 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Holiday mailings

 >      I presume a lot of group members will be disapearing off home for the summer

 >      soon, or have even gone already. I will still be around a fair bit over the

 >      summer months, so at least I will be reading! Will there be anyone else?

 >      	Richard.

 >

  I will still be around. I generally log in from home over a modem line about once a week during vacations

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: Holiday mailings1
Date: Fri, 19 Jun 92 12:47:55 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Holiday mailings

I do the same (log on my phone that is), but I'm not sure what the state

of the teching system will be over the summer, so if you get a bounce have a go with mbacsry@mcchpc.mcc.ac.uk It MIGHT work.

Richard.

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     :


No Subject4
Date: Fri, 19 Jun 92 02:12:25 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject:

Hi all

In Reply to Richard's note:

I will be around for the Summer, I normally log on over a modem line during the summer so I'll be Reading and Asking (questions that is!!)

I will be away for the next 12 days or so, and I will talk to ye all then!

Stephen.

Trinty College,

Dublin, Ireland.


Re: Holiday mailings2
Date: Fri, 19 Jun 92 10:39:13 BST

From: Thomas J Hughes <thughes@dcs.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: Holiday mailings

In reply to Richard York

>I presume a lot of group members will be disapearing off home for the summer

>soon, or have even gone already. I will still be around a fair bit over the

>summer months, so at least I will be reading! Will there be anyone else?

I shall be here for another two weeks, then away until the begining of October, although there may be a period of six to seven weeks in the middle of that when I do read this from work (depends how much traffic there is likely to be on this group over the summer really...)

Tom.

============================================================================ Tom Hughes, CS2

thughes@uk.ac.warwick.dcs            57 Shakleton Road cstaqdb@uk.ac.warwick.csv            Earlsdon

                                     Coventry

(0203) 673584                        CV5 6HT ============================================================================


Re: Holiday mailings3
Date: Sat, 20 Jun 1992 08:39:52 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Holiday mailings

Richard York <yorkr@p4.cs.man.ac.uk> writes:

> I presume a lot of group members will be disapearing off home for the

> summer soon, or have even gone already. I will still be around a fair bit

> over the summer months, so at least I will be reading! Will there be

> anyone else?

Well I get my email at home, so I'll be here all the time...

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


Re: Holiday Mailings4
Date: Fri, 19 Jun 92 23:23 GMT

From: Alan Ralph <aralph@cix.clink.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Holiday mailings

Richard York writes:

>I presume a lot of group members will be disapearing off home for the

>summer soon, or have even gone already. I will still be around a fair bit

>over the summer months, so at least I will be reading! Will there be

>anyone else?

Yep. Mine's a commercial account, so barring a major financial mishap on my part, I'll be around for those with nothing better to do but reminisce about the 'good old days' :-)

Alan.


Re: Holiday mailings5
Date: Mon, 22 Jun 92 22:41:43 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Holiday mailings

> Yep. Mine's a commercial account, so barring a major financial mishap on

An Arc, for example?! :-)

> my part, I'll be around for those with nothing better to do but reminisce

> about the 'good old days' :-)

>

> Alan.

>

I'll still be using my accounts here at Loughborough from back home, so no doubt you'll all be hearing from me anyway! (I expect to see Alan on Challenger of course :-)...). I'll probably be going on about fun using 32016 2nd processors! (I hope!).

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: Holiday mailings6
Date: Fri, 26 Jun 92 00:21 GMT

From: Alan Ralph <aralph@cix.clink.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Holiday mailings

RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk> writes:

>> Yep. Mine's a commercial account, so barring a major financial mishap on

>An Arc, for example?! :-)

I'm sorely tempted to empty my NSB Investment Account and blow it away on one... shame they're so bleedin' expensive!!!!

>> my part, I'll be around for those with nothing better to do but reminisce

>> about the 'good old days' :-)

>>

>> Alan.

>I'll still be using my accounts here at Loughborough from back home, so no

>doubt you'll all be hearing from me anyway! (I expect to see Alan on

>Challenger of course :-)...). I'll probably be going on about fun using

>32016 2nd processors! (I hope!).

I wouldn't mind having one of these 32016 boxes... I could grab some sources from CIX and port them to PANOS, and have hours of fun! Expect me round your house with a baseball bat shortly :-)

>Regards,

>Richard.

Alan.


Morley RAM disc
Date: Fri, 19 Jun 1992 04:58:08 +1200

From: julian <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Morley RAM disc

Hi all.

A while ago my Dad purchased one of those Morley RAM discs. It has 1Mb of RAM in it, interfaced via 1MHz bus. It is a wonderful device, providing 256 'subdrives' (virtual drives) and a DFS-like interface to each subdrive.

There are two major obvious differences between the ramdisc filing system and DFS... each subdrive can have as many files as it likes in the catalogue, and you don't need to compact the files. There are also a number of cosmetic differences... the catalogues are not sorted by either filename or directory letter, but outputs filenames in the order they were first saved...

However, it is incompatible with ADFS, to the point of the machine not functioning if ADFS is present. The only way to get it going on such a machine is to disable ADFS. I was wondering if anyone knows whether Morley ever produced an update to the software which was more ADFS-friendly, before they stopped selling the ramdisc?

I wrote a custom drawing program for the beeb-with-ramdisc which could plot and print out images much larger than one screenfull. In fact you could create a virtual screen three physical screens wide by however many you wanted deep. (The horizontal limit is due to the printer not being able to print any wider). When editing you can scroll around the virtual screen with the CTRL-cursor keys. The physical screen is a custom 256x256 pixel "square Mode 4" screen. Is there anyone else out there with a morley ramdisc who might be interesting in seeing this software?

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


Morley RAM disc1
Date: Fri, 19 Jun 92 10:58:02 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Morley RAM disc

> Mode 4" screen. Is there anyone else out there with a morley ramdisc who

> might be interesting in seeing this software?

>

>     Cheers, Julian.

Hi!

I have an Opus Challenger 3 silicon disk system (well, actually 2 of them - one gets used to run the BBS) which has two 256K silicon disks operating like normal DFS disks (you can 'format' them to 100k, 200k or 256k depending on how any perculiar software likes them). Its also on the 1Mhz bus, although it also incorporates a complete 1770 and upto 3 extra normal disk drives (so you can have drives 0-7, 2 of which are the silicon disk drives, you can config any drive number as another). You don't even need a DFS in your micro, just a ROM for the unit, so you can have PAGE at E00. I haven't found anything that doesn't work on it apart from Tube Elite (normal Elite does) and my Ample Music 5000 system (which is also on the 1Mhz bus - the two can still be running on the 1Mhz bus when using the Music 5000, but you can't actually use any of the 'Challenger drives' to load the software).

Apparently you can use ADFS on it if you have a Master (haven't got the ROM image to do this, so I haven't tried). It seems to be a very useful unit, and very compatible with life. (although when new, they were 250quid...but a lot less secondhand now).

Would your software run on this silicon disk do you think?

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


EtherNet
Date: Fri, 19 Jun 92 15:40:02 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: EtherNet

Having got a number of machines, and second processors, and hoping to aquire a hard disc in the near future:

How dificult/expensive would it be to set up an ethernet?

Whats the cost per machine these days?

Do I realy need two active terminators, costing silly amount of  money?

What about the clock signal?

What is performance like compared to local discs, when the network is  lightly loaded?

Basicaly would it be silly to place my hard disc on a file server, and access it accros then net, when there is only likely to be a  single user at any one time. (NFS's file protection is a consideration here - other people may use the system too, an I'd like  to be able to protect files).

Ian


Re:  EtherNet
Date: Fri, 19 Jun 92 16:22:53 BST

From: Richard York <yorkr@p4.cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re:  EtherNet

surely you aren't talking about etherneting BEEBS are you?????

I can't imagine how difficult this would be. Isn't econet a bit more realistic?

 	Richard.

ps just egnore me if I'm on totally the wrong wave length!

pps I am now heading off home. Will log on again in about a week. Byeeeee.

: Richard York                   :   E-mail : yorkr@p4.cs.man.ac.uk    :

: 2nd year Computer Engineering  :   Janet  : yorkr@uk.ac.man.cs.p4    :

: Manchester University          :                                     :


Re: EtherNet1
Date: Fri, 19 Jun 92 16:54:03 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: EtherNet

>surely you aren't talking about etherneting BEEBS are you????? I can't

                                 ^^^^^^^^^^^

>imagine how difficult this would be. Isn't econet a bit more realistic?

>	Richard.

Ooopss - Quite correct I am stupid !!!

I meant econet - force of habbit

:%s/ethernet/econet/g

Ian Stephenson


Screen Compression
Date: Fri, 19 Jun 92 17:14:29 +0100

From: ic1@ukc.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: Screen Compression

Hello everyone,

Can anyone recommend ( and hopefully tell me how to get hold of ) a good graphics screen compression program for the beeb. I've been converting PBM files into beeb mode 0 screens but they are taking up loads of disc space. I'm using a BBC master and the files are saved on ADFS floppies.

Thanks for your time,

ian

P.S. I go home next tuesday and wont be able to read mail again until

     October :-(


Re: Screen Compression
Date: Fri, 19 Jun 92 17:24:19 BST

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Screen Compression

A short(ish) assembler routine was published in acron user a (long)  while back to do run length encoding - It was able to do some usefull  compression (it had a tweak in to ensure better performance for  elternating pixels too). However how good its performce would be on  REAL images I've no idea (pretty poor I would guess).

Ian


IBM Reader
Date: Sat, 20 Jun 92 20:33:23 BST

From: Jason O'Broin <J.P.O'Broin@durham.ac.uk>

To: bbc-list-request@ohm.york.ac.uk

Subject: IBM Reader

I've finally picked up my IBM Disk Reader from home and am ready to distribute it in the next few days.

However, how would people like this distributed. I don't have access to a Beeb here in college, and I'm only here until 1st July.

My current thought is to spark +uuencode on my arc and then send it to comp.sources.acorn for distribution.

Please note, this software is reasonably stable, but hasn't been touched for 3 years. I have no plans to do anymore work to this program, but I'm very happy for others to work on it.

Jason.


Econet
Date: Sun, 21 Jun 92 18:52:26 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Econet

  Happens to be my speciality...Could you describe exactly what you have and want to do and I'll try and help


Re: Econet
Date: Tue, 23 Jun 92 19:29:17 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: ian@ohm.york.ac.uk

Subject: Re: Econet

if all you have are two machines then one will have to become a dedicated server which means that you can only use one of them. (the server must have a 6502 2nd processor BTW)

The performance with only two machines, one of which is the server would be not much less than a local drive (certainly faster than floppies).

The cost is erm.. 86 pounds and 9 pence ecluding VAT in september 1990 (thats the price for an Econet starter pack which I think includes a length of cable, two terminators and a clock. obtaining the old level 3 software might be tricky as it is no longer supported by Acorn. Our school has it and it is very reliable

to run a network you need (as a minimum), a length of 5 core screened cable, two terminators, a clock and a server. A printer server is nice too.

I think this answers your questions. If you want to know more then let me know.

I just realised this crummy mailer (I cant use the normal one on my terminal at home) hasn't sent this to the list but to you, feel free to post whatever you like from it if you think someone might find it useful)

Mik


BBC micro VT200 (plus) emulation?
Date: Thu, 25 Jun 92 19:28:48 +0100

From: CONCO (Falmer) Ltd <kierant@central.susx.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC micro VT200 (plus) emulation?

Sorry if this is an old chestnut (!), but is there anyone out there with a vt220 (or similar/better) emulator that I can link in to my modem software (I'll do that, just need the emulation) so that the software that I have to use when connecting to Uni remotely doesn't blow up?

Many thanks for any suggestions!

;-) K


BBC micro VT200 (plus) emulation?1
Date: Thu, 25 Jun 92 20:03:07 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC micro VT200 (plus) emulation?

> Sorry if this is an old chestnut (!), but is there anyone out there

> with a vt220 (or similar/better) emulator that I can link in to my

> modem software (I'll do that, just need the emulation) so that the

> software that I have to use when connecting to Uni remotely doesn't

> blow up?

>

> Many thanks for any suggestions!

>

> ;-) K

There are several vt100 terminal emulators around...vt220 doesn't offer vast quantities of extra goodies that are frequently used does it? I'd be interested if anyone has a vt200 or vt220 terminal for the beeb. Communicator, Uniterm and Termulator all have vt100 emulators in differing degrees of full-ness. (none of them do flashing text, mind you that is a little difficult in Mode0/3).

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


BBC Micro VT100 emulation
Date: Wed, 1 Jul 92 20:07:43 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: bbc-list@ohm.york.ac.uk

Subject: BBC Micro VT100 emulation

Is there commucations software around for the beeb that is good at emulating VT100 controls codes??

I have a master at the moment and it contains the Terminal software - but the manual has very little information on the package, Is there anywhere or anyone who can tell me more about the software???

Stephen.


BBC Micro VT100 emulation1
Date: Wed, 1 Jul 92 22:44:11 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC Micro VT100 emulation

> Is there commucations software around for the beeb that is good at emulating

> VT100 controls codes??

Several do a reasonable job - I posted a message about them before I think... Communicator (still commercially available, although expensive), Termulator (not so exciting for vt100, still available), Uniterm...Plenty of vt52 terminal emulations around too...Kermit for a start.

> I have a master at the moment and it contains the Terminal software - but the

> manual has very little information on the package, Is there anywhere or

> anyone who can tell me more about the software???

>

> Stephen.

>

Its a pretty minor piece of terminal software...it probably supports most of vt52 on a good day. If you send it vt100 stuff then it tends to beep a lot at most stuff (although screen remains intact), so its advisable to turn the sound off! Good enuff for a minimal dumb/vt52 requirements, but not exactly comprehensive...I believe the master manual(s) may mention a few sentences or so on the topic (can't remember)...

Regards,

Richard.


Re: BBC Micro VT100 emulation2
Date: Thu, 02 Jul 92 10:32:04 +1200

From: Pat Cain <patrick@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: BBC Micro VT100 emulation

smcgnnss@unix2.tcd.ie (Stephen McGuinness) writes:

> Is there commucations software around for the beeb that is good at emulating

> VT100 controls codes??

There's a VT100 emulator rom that does vt100, tektronix etc.  If you're desperate then I'll mail it to you uuencoded.  Dave Sainty (who is away on holiday this week) wrote TequilaComm which is a very nice BBC comms package.  I've used it on the master and it's 100 times better than Modem Master which is what I used to use.  Features like scrollback, X and Y modem, around about VT220 support (even does double height, width etc. under vt100).  It's got a nice dialling directory with autologin scripts etc.  There's a shareware version and the full version is NZ$30 which is about 10 pounds.  If you want the shareware version then send mail to <cain_p@kosmos.wcc.govt.nz> and I'll mail it uuencoded.

> I have a master at the moment and it contains the Terminal software - but the

> manual has very little information on the package, Is there anywhere or

> anyone who can tell me more about the software???

There is some more documentation about the Master's Terminal software in one of the Reference Guides.  But it's really not worth it, it has a very poor ansi emulation, I'd suggest TequilaComm.


Re: BBC Micro VT100 emulation3
Date: Fri, 3 Jul 1992 13:16:18 +1200

From: julian@bridge.welly.gen.nz

To: bbc-list@ohm.york.ac.uk

Subject: Re: BBC Micro VT100 emulation3

Pat Cain <patrick@sideways.welly.gen.nz> writes:

[Talk about Tequilacomm]

> is NZ$30 which is about 10 pounds.  If you want the shareware version

> then send mail to <cain_p@kosmos.wcc.govt.nz> and I'll mail it uuencoded.

It's already on shiraz.ohm.york.ac.uk ... I FTPed it there several weeks ago for Dave, and posted  not to this list about it...

    Cheers, Julian.

--

----------------------------| RO2:SYS 68,59243844 |-------------------------- wright_j@kosmos.wcc.govt.nz |---------------------| "I'm sig of sicknatures!" ----------------------------| RO3:SYS 68,60816742 |-------------------------- --


My system has changed
Date: Wed, 12 Aug 92 15:10:26 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: My system has changed

Since we all mailed each other giving details of our systems, my system has undergone some fairly major changes. Here is its new look:

BBC B, PCB rev 3.

with an ATPL ROM expansion board & 16K of Sideways RAM

and a 1772 Disc Controller.

OS	1.20

BASIC	2

ADFS	1.30

SRAM	1.05

DFS	2.26

Other ROMS:

Wordwise-Plus	1.4F

EXMON	1.0A

Toolkit	1.23

HCCS Forth	Issue B

6502 2nd Processor, with HiBASIC 3 & 4 and HiView

Z80  2nd Processor, with no software

2 double-sided 80T 5.25" disk drives

CUB 14" Hi-Res monitor

SCSI Interface card (Not yet powered up - no SCSI disk yet)

Since recently aqquiring a 1772 Disc controller, the 80T drives and ADFS I am currently moving my old S/W from 40T DFS discs to 80T ADFS discs. Thus far the transition has been fairly smooth, apart from my copy of Elite, which didn't like the 1772. This has been happily resolved after aquiring the 6502 2nd processor with a copy of Elite that is really amazing.

Does anyone have any manuals for HiView (or View?). I currently cannot use it as I don't know any of the commands.

Matthew

matthew_sweet@tadtec.uucp


A group project...
Date: Mon, 7 Sep 92 10:42:52 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: A group project...

Hi,

A lot of people complained that there wasn't a decent 'C' compiler for the BBC when this list was set up.

How would people like to remedy this situation?

My suggestion is that the group get together and write a multi-pass C compiler for the 6502 that is capable of running on a BBC B.

The aim would be to make the system modular, so that the front-end could be re-used for other CPUs (Z80, 32016, etc), but only a 6502 back end would be written.

As I see it, on a limited memory machine like a BBC, a the compiler should use disk as its workspace. A C file on disk should be run through each stage, producing another disk file.

The following need to be done:

All interested need to express this interest!

A discussion of minimum H/W required should be held. While the final product may execute on a standard BBC B, is it acceptable if it can only compile itself on a BBC B with a second 6502?

The development tools to be used should be discussed. A final aim would be to have the C compiler in C, however this needs you to be able to compile C to start with...

Do we use tcc as an initial development tool, writing C code that will compile on tcc? Do we write full C and get one of the group to initially compile it using BEEBUG C (a full implementation of C that compiles to code for a virtual machine that is then emulated by the BBC) and then itself?

What S/W architecture do we use in the final objects?

- the stack supplied is probably too small for C.

- do we place an arithmetic stack between &400 and &800?

- how do we use zero page (my suggestion is as "registers")

- what calling convention should we use?

- Which functions can be placed in a ROM for non-standalone use in standard BBCs? - Arithmetic primitives are an obvious choice.

At least an assembler and a linker need to be produced, (65as and 65ld)? These would then be used as final stages of translating 'C' to 6502 assembler. Possibly the tcc utilities could be used/extended.

Matthew


Re: A group project...
Date: Wed, 9 Sep 92 09:15:07 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: A group project...

  I mentioned this same idea to some people on another system a while back and was met with not a great deal of hope but if it could be pulled off then I'm all for it.

  Anyone else reckon this is a good idea (or even a workable idea)

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: A group project...1
Date: Wed, 9 Sep 92 12:40:54 +0100 (BST)

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: A group project...

I'm happy to go for the compiler project - I think it is doable, if  we can get about four or five people who know what they're doing (or  at least can work it out in a reasonable time!).

It may be best to start from a real C compiler, such as GCC or similar and port it to a virtual machine, then compile that to 6502,  and then assemble and link that.

The only practical way of developijng the system (I think) is to work  on "BIG" machines, and build a cross compiler, using all the tools  available, and targetting to the second processor. Once thats going  then we then bootstrap the compiler onto the BBC. Trying to develop on the beeb will be impossible as there are no tools for doing so  (thats the whole point!).

I'll volenteer to write the assembler and linker, as I've written  assembers before.

Ian


BBC File transfer
Date: Fri, 2 Oct 92 10:20:06 +0100 (BST)

From: I Stephenson <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC File transfer

Hi All,

I just received the following enquiry from Chris Robey. I've added him to the list, and enclose his plea for help. So has anyone got any brilliant idea on this? I'd also be pretty interested to here them if you have.

Ian

Begin forwarded message:

Date:    Fri, 02 Oct 92 09:02:05 BST

From:    Chris Robey <CJR1@IBM-B.RUTHERFORD.AC.UK>

Subject: BBC File transfer

To:      ian@ohm.york.ac.uk

 Hello,

I realise that you may not be the right person to talk to but seeing as I saw your name written on a BBC archive service I thought that you may be the best person to ask.

This is my problem/request :-

I have a BBC Micro at home and I want to transfer the files from it (on a 3.25 inch drive, or it may be 3.50 inch, i can never remember, anyway the standard size) to my SPARC at work (that has the said disk slot built in)

Are there any programs that can read files from a BBC formatted disk ONTO the SPARC?

This would be a great asset to me as I would then be able to work from home. If you cant help with this request perhaps you could point me in the direction of someone that can (may?).

Anyway, thanks for your time and help.

Chris Robey


BBC File transfer1
Date: Sat, 3 Oct 92 2:33:02 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC File transfer

Hi,

> I have a BBC Micro at home and I want to transfer the files from it (on a

> 3.25 inch drive, or it may be 3.50 inch, i can never remember, anyway the

> standard size) to my SPARC at work (that has the said disk slot built in)

>

>

> Are there any programs that can read files from a BBC formatted disk ONTO

> the SPARC?

>

>

> This would be a great asset to me as I would then be able to work from home.

> If you cant help with this request perhaps you could point me in the

> direction of someone that can (may?).

>

Are these just simple text files that you are transfering?

If you have a 1770 disk interface on your BBC then there are a number of PC<>MSDOS disk transfer utilities you could use to transfer stuff to and from PC format disks...can your SPARC read PC format disks?

If you can get the two machines together (this may not be a practical solution!) you can link them up via the serial port and chuck stuff to and fro that way...

Haven't heard of a SPARC disk reader for the beeb, doubt there is one, although there's enuff expertise out there to write one, unless the SPARC uses a disk format with more than 800k/disk, in which case life gets difficult.

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


I see this list has got off to a flying start this term
Date: Tue, 20 Oct 92 15:36:24 +0100

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: I see this list has got off to a flying start this term

---------------------------------------------------------------------------

|         Michael Davis           |   If you can keep your head when all  |

|    davism@uhura.aston.ac.uk     |   around are losing theirs, you're    | |_________________________________|   probably the executioner            |


Re: I see this list has got off to a flying start this term
Date: Tue, 20 Oct 92 16:22:29 MET

From: Gerben 'P' Vos <gpvos@nl.vu.cs>

To: The BBC mailing list <bbc-list@ohm.york.ac.uk>

Subject: Re: I see this list has got off to a flying start this term

Yeah, it's hard to keep up with the volume, isn't it?

<>< Gerben.


My latest....
Date: Thu, 12 Nov 92 01:58:30 +1300

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: My latest....

Phew, I always get a little nervous when I start playing about with the guts of my machine, especially when in trial runs it won't even give the startup message!

But I've managed an interesting addition to my model B today. This won't be of practical use to master users btw...

The Master has an 8k block of memory from &C000 to &DFFF which is paged with the VDU routines if I'm correct.... and allows roms to claim this memory leaving main memory free.

I've done the same to my model B.

At least, the hardware is done, I shall have to write some software to accomodate the new memory, the main aim is to use the master ADFS with my still non-functional hard drive, thus saving me the bother of finishing my filing system which was probably more trouble than it was worth.

Because the vdu routines in the model B are a little smaller, I couldn't include the full 8k, in particular, the interrupt routines are part of that 8k! I've used an 8k chip though, and in fact have two 4k blocks pageable to teh same location (&C000). That will not have much practical use, but could be useful for my own software wanting workspace I guess.... Good for resident programs that don't collide with other programs!

The whole circuit is only two chips, a 6264 (8k static ram), and a 74F139. I don't know whether the 139 need be fast (F) but it was only $2 for the chip! the 6264 I don't know the price, it was part of my original 16k SRAM design, where I piggybacked two 6264's. I did the same in this project, and it looks very ugly! :-) The 6264 sits under the OS rom, and the 139 dangles to the side. It's a bit crammed, so I shall check later for heat problems. But the ram chip is CMOS, so keeps pretty cool.

The pages are currently switched by the user port, one bit for selecting ram, one for selecting which bank of ram.

Do people want the full constructional details posted here? Are people interested in getting roms running master style on their beebs?

It's not very hard to make, it just took me this afternoon and evening, and I had some problems as I was basically making it on the fly. But you would have to be reasonably competent with a soldering iron, and not be too nervous about performing surgery on their machine. And, or course, I take no responsibility for any damage caused by people making my project.....

Dave.


TequilaComm2
Date: Wed, 16 Dec 92 20:56:34 +1300

From: Dave Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: TequilaComm

My comms program TequilaComm has been in production for so long now! I've been attempting to find a reasonable method of distributing it, with little luck. (No ftp site seems stable enough to put it there!)

So I've given up!

I shall now simply mail it uuencoded to anyone wishing a copy of the shareware version. I would appreciate it being distributed locally by people wishing a copy now, in order to keep mailing to a minimum. It will be a fairly large sized file! (I shall zip the file, and I'll also bundle in my UnZipper, to make sure no-one has any difficulty with this).

Mail me if you wish to get a copy in this way.


Real Time Clock (and other stuff)?
Date: Tue, 12 Jan 93 10:51:48 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Real Time Clock (and other stuff)?

Hi y'all!

There hasn't been much traffic on here recently, but there are a few bits that I thought were worth throwing about.

Does anyone have a design for an Acorn compatable real time clock? I remember discussing this with Mathew last summer. Could we put together a production run? (How about it Richard?).

(I'm gona get my hard disc REAL SOON. honest!)

Is anyone interested in using their BBC as a graphics terminal? I've been developing an objective C based graphics library recently. It currently runs under X, but I've been keeping in mind that it should be easily addapted to drive BBC VDU codes?

Has anyone got any good mouse based software? I'd realy love to get hold of something like AMX framemaker. Also does anyone have a commercial (ie good quality) C compiler?

Finaly remember that just 'cause the BBC is old, it doesn't mean that it can't do everything it could when you bought it. I recently wrote a package to analyse some Scanning Electron Microscope data (for my girlfriend - it would have taken her MONTHS). The BBC did the job just as quick as anyth ing else could have.

Ian Stephenson

ian@ohm.york.ac.uk


Re: Real Time Clock (and other stuff)?1
Date: Tue, 12 Jan 93 15:06:51 GMT

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Real Time Clock (and other stuff)?

 >      Hi y'all!

 >      	There hasn't been much traffic on here recently, but there

 >      are a few bits that I thought were worth throwing about.

 >

 >      	Does anyone have a design for an Acorn compatable real time

 >      clock? I remember discussing this with Mathew last summer. Could we

 >      put together a production run? (How about it Richard?).

 >      (I'm gona get my hard disc REAL SOON. honest!)

  Would the one used by the old level 3 econet server provide a starting point?

It would have to be compatible (at least command-wise) with the BBC master one.

 >

 >      	Is anyone interested in using their BBC as a graphics

 >      terminal? I've been developing an objective C based graphics library

 >      recently. It currently runs under X, but I've been keeping in mind

 >      that it should be easily addapted to drive BBC VDU codes?

  How about a system to allow a BBC to run as a terminal to an archimedes such that the arch. acted as a "second processor" kind of arrangement (probably over the serial port). The arrangement would have to be a piece of software running both ends such that any i/o requirements were processed by the beeb but the number crunching bits were done by the arch....

 >

 >      	Has anyone got any good mouse based software? I'd realy love

 >      to get hold of something like AMX framemaker. Also does anyone have a

 >      commercial (ie good quality) C compiler?

 >

 >      	Finaly remember that just 'cause the BBC is old, it doesn't

 >      mean that it can't do everything it could when you bought it. I

 >      recently wrote a package to analyse some Scanning Electron Microscope

 >      data (for my girlfriend - it would have taken her MONTHS). The BBC

 >      did the job just as quick as anything else could have.

  Mik (currently trying to write a decent version of tetris for the beeb)

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

Some people in this department wouldn't recognize subtlety if it hit

them on the head.


Re: Real Time Clock (and other stuff)? (fwd)
Date: Wed, 13 Jan 93 13:59:06 GMT

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Real Time Clock (and other stuff)? (fwd)

>   How about a system to allow a BBC to run as a terminal to an archimedes

> such that the arch. acted as a "second processor" kind of arrangement

> (probably over the serial port). The arrangement would have to be a piece

> of software running both ends such that any i/o requirements were processed

> by the beeb but the number crunching bits were done by the arch....

>

The serial port would be too slow, even at 38400...anyhow, any of the old Arcs or any Arc with RO3.1 wouldn't be able to keep up with the beeb at that speed anyway...and 9600 is certainly too slow.

Best bet is to wangle something with the 1Mhz bus, or even the Tube, or buy a second hand 32016 2nd proc, or even ARM 2nd proc (let me at one!) :-)

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: Real Time Clock (and other stuff)?2
Date: Wed, 13 Jan 1993 09:40:52 +1100 (EST)

From: Andrew Leahy <A.Leahy@st.nepean.uws.edu.au>

To: ian@ohm.york.ac.uk (I Stephenson)

Subject: Re: Real Time Clock (and other stuff)?

> 	Is anyone interested in using their BBC as a graphics

> terminal? I've been developing an objective C based graphics library

> recently. It currently runs under X, but I've been keeping in mind

> that it should be easily addapted to drive BBC VDU codes?

YUP!

Last year (sorry, the year b4 last !) I wrote a program to

"convert/filter/whatever-u-like" PPM files (Portable PixMap) into VDU codes. I used it to display images (GIF/JPEG/etc.) on my Beeb at home while logged into Uni. over the modem. And it displayed them in REAL colour too! (using ppmquant to convert images to 3-bit colour in MODE2 or 2 bit colour in MODE1 - sounds sh*t - looked great - for the beeb anyhow :)

But, since we got a new terminal/modem server (Annex) running off the Unix box (Ultrix)...I haven't been able to get it to work...arrgggghh!

> 	Has anyone got any good mouse based software? I'd realy love

> to get hold of something like AMX framemaker. Also does anyone have a

> commercial (ie good quality) C compiler?

AMX Pagemaker...yup...not to bad...bit clumsy on the Beeb though, swapping discs all the time. Works better with a RAM disc.

Don't BEEBUG sell a C compiler for the Beeb? __________________________________________________________________________

Andrew "Alf" Leahy                  phone: (047) 360771 (W) irc: pepsi-alf

Uni. Western Sydney, Nepean.        Remote-email: alf@st.nepean.uws.edu.au

Sydney, Australia.                  Local-email: alf


Graphics Library+bits
Date: Wed, 13 Jan 93 10:39:06 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Graphics Library+bits

> Last year (sorry, the year b4 last !) I wrote a program to

> "convert/filter/whatever-u-like" PPM files (Portable PixMap) into VDU codes.

> I used it to display images (GIF/JPEG/etc.) on my Beeb at home while logged

> into Uni. over the modem. And it displayed them in REAL colour too! (using

> ppmquant to convert images to 3-bit colour in MODE2 or 2 bit colour in MODE1

> - sounds sh*t - looked great - for the beeb anyhow :)

>

So where can we get this wonderfull pice of software?

2bit colour isn't too bad for viewing images - the NeXT I use has 2bit grayscale, and still manages to make a good go of it (though of course its higher resolution).

The toolkit I've been developing is a set of objects (buttons, sliders, panels etc) to facilitate mouse based software. Its an attempt at a (very) simple NeXTStep copy - just enough to allow me to port my programs to X. I've deliberatly avoided using such features as bitplanes to enable me to po rt to other platforms. Targetting to BBC codes would be simple, but it requires objective C on the host machine.

GNU CC almost supports this (there's no runtime just yet) so the Arc is a possible, and a commmercial compiler is available for most other platforms, but the only place its common is on NeXT's. Its an excellent language - much better than C++, as its far closer to smalltalk. Expect to see it tak eover the world real soon!

If anyone has access to Obj C then I'll mail them the X targetted version, and we can sort something out. Otherwise I'll consider doing the conversion ready for when GNU Obj C starts working.

> AMX Pagemaker...yup...not to bad...bit clumsy on the Beeb though,

>swapping discs all the time. Works better with a RAM disc.

But if I put it on a hard disc...

>Don't BEEBUG sell a C compiler for the Beeb?

As did Acorn - I've got a manual for one of these (can't remmeber which) but never got the software itself. I've got Acorn's ISO Pascal which is excellent (if you like pascal) so it is possible to write real compilers.

>  Mik (currently trying to write a decent version of tetris for the beeb)

Gimmie! Gimmie!

Ian


Re:  Graphics Library+bits
Date: Wed, 13 Jan 93 14:16:29 GMT

From: David Alan Gilbert <gilbertd@cs.man.ac.uk>

To: ian@ohm.york.ac.uk

Subject: Re:  Graphics Library+bits

Gnu c is not available for the Arc as yet due to the way the arc handles memory (grrr!) - I mean lets face it - you haven't been silly enough to use malloc and free have you ( or alloca) - because it just wont like it in the Arc environment.

Dave


Re:Real time clock, and BBC as a graphics terminal
Date: Wed, 13 Jan 93 08:52:49 GMT

From: David Alan Gilbert <gilbertd@cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re:Real time clock, and BBC as a graphics terminal

There was a real time clock circuit published in Micro User a LONG time ago - say around 8 years? Also there is the alternative - there used to be a firm who embedded RTC's into 6264 RAM sockets.

As for using a BBC as a graphics terminal off an Archimedes, it probably isn't too bad - except for 2 hickups:-

1) If you try looking at the output from the WIMP , there is nothing in the VDU stream about sprites, fonts and the Draw module.

2) It would be difficult to run a seperate task - i.e. a seperate wimp say down the serial port. It wouldn't be TOO difficult to run simple programs in a task window and force the result down the serial port.

Dave


Re: Re:Real time clock, and BBC as a graphics terminal1
Date: Wed, 13 Jan 93 13:19:24 GMT

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Re:Real time clock, and BBC as a graphics terminal

 >      As for using a BBC as a graphics terminal off an Archimedes

 >      , it probably isn't too bad - except for 2 hickups:-

 >

 >      1) If you try looking at the output from the WIMP , there

 >      is nothing in the VDU stream about sprites, fonts and the Draw

 >      module.

 >

 >      2) It would be difficult to run a seperate task - i.e. a seperate

 >      wimp say down the serial port. It wouldn't be TOO difficult

 >      to run simple programs in a task window and force the result

 >      down the serial port.

  This latter is what I was thinking of. Basically running BBC programs but getting the ARM to do the hard work whilst the beeb handled all the i/o. Much the same idea as using a BBC B with a 6502 or Z80 (or 32016) second processor hung off the tube.  Youd have to be careful that the arch. didnt filter out any odd characters which it considered to be unsuitable for a task window (try calling up a task window and doing a mode change - nothing happens. I dont know at what level this filtering takes place though.

  Mik

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

A university is what a college becomes when the faculty loses interest

in students.

-- John Ciardi


Re: Re:Real time clock, and BBC as a graphics terminal2
Date: Thu, 21 Jan 1993 21:52:13 +1300

From: <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Re:Real time clock, and BBC as a graphics terminal

"Mik Davis" <davism@uhura.aston.ac.uk> writes:

>   Youd have to be careful that the arch. didnt filter out any odd characters

> which it considered to be unsuitable for a task window (try calling up a task

> window and doing a mode change - nothing happens. I dont know at what level this

> filtering takes place though.

TaskWindow does this as a default action. You can open a taskwindow with *all* characters (ctrl or otherwise) passed through verbatim by using the '-ctrl'

option on the *TaskWindow command.

--

I'm here to chew gum and kick ass - and I'm all outta gum...


Re: Re: Re:Real time clock, and BBC as a graphics terminal3
Date: Fri, 22 Jan 93 11:44:45 GMT

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list-request@ohm.york.ac.uk

Subject: Re: Re: Re:Real time clock, and BBC as a graphics terminal

 >"Mik Davis" <davism@uhura.aston.ac.uk> writes:

 >

 >>   Youd have to be careful that the arch. didnt filter out any odd characters

 >> which it considered to be unsuitable for a task window (try calling up a task

 >> window and doing a mode change - nothing happens. I dont know at what level this

 >> filtering takes place though.

 >

 >TaskWindow does this as a default action. You can open a taskwindow with *all*

 >characters (ctrl or otherwise) passed through verbatim by using the '-ctrl'

 >option on the *TaskWindow command.

 >

  Even so, you'd then have to trap these characters yourself. Not being an Archimedes programmer I really don't know whether this would be possible.

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

Next Friday will not be your lucky day.  As a matter of fact, you don't

have a lucky day this year.


Re:  Real Time Clock (and other subjects)?
Date: Wed, 13 Jan 93 10:09:40 GMT

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: Re:  Real Time Clock (and other subjects)?

Happy New Year to all.

Ian writes:

>	Does anyone have a design for an Acorn compatable real time

>clock? I remember discussing this with Mathew last summer. Could we

>put together a production run? (How about it Richard?).

I was thinking of using a chip with 2k-8bytes of NVRAM as well as a battery backed RTC. This and a bit of glue logic & space for some other RAM...I _might_ even be able to get a good price on the RTC chip as Tadpole buy them in quantity.

>(I'm gona get my hard disc REAL SOON. honest!)

I know the feeling. I still have not got around to getting one.

> Also does anyone have a

>commercial (ie good quality) C compiler?

I have most of a copy of CC's Beebug C compiler (which compiles ANSI C to P-code, and emulates a P-code machine). Sadly, I am unable to lay my hands on one of the two ROMs, which is missing. CC will sell either the entire package (50+ sterling) to anyone, or the single ROM (12+ sterling) to the original purchaser of the software.

I have been unable to persuade CC to part with just the second ROM, despite having proof of a direct line back to the original purchaser. I have contacted the original purchaser, and he is unable to buy the ROM and sell it on - even as a favour. The educational site he works for have got rid of their BBC 'C' package (to me) and can no longer buy things for it. He did send me a rather nice letter, but CC won't accept this.

(Any chance of tcc sometime Ian?)

Does anyone have some cheap modems & S/W? - I need a way of getting stuff from work to home (and back). Currently this is very hard, as nothing at work understands DFS or ADFS format disks.

>	Finaly remember that just 'cause the BBC is old, it doesn't

>mean that it can't do everything it could when you bought it.

Too right. After using SPARC & 88110 stuff at work it is quite fun trying to get the trusty old BBC to do something meaningful!

Sometime soon I shall post my fixed-point 6502 assembler routines, and the mandelbrot program that spawned them. I suspect that there is a much better (but similar) algorithm to the one I use, but haven't finished playing with the set-up yet.

Matthew Sweet

matthew@tadtec.co.uk


beeb RTC
Date: Thu, 14 Jan 93 15:48:28 GMT

From: richard york S92 sbf <yorkr@cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: beeb RTC

On this subject I have already built one, and it did work, though it was a

bit touchy due to my rather poor PCB. It fits into the speech socket and

uses the RTC chip used in the Master and many other machines. My design has

a battery on it, and a few bits to support the battery and my glue logic.

I have in my draw a device made by dallas Semiconductors which is pin

compatible and includes a battery and all the crystal circuitry inside it.

This means I can do away with about half of the board are and bits.

Is anyone interested, since if they are I will persue it a bit more?

Richard


Forwarded Request
Date: Wed, 20 Jan 93 11:52:45 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Forwarded Request

I'm forwarding this from uk.misc - anyone any info?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

OK, this is a bit sad perhaps, but I'm looking for a disassembly (commented, hopefully) of some or all of the OS ROMS for the BBC Micro. (Specifically around the buffer areas).

Anything accepted with thanks - email please

ta

john N

--

john nicoll (jkn@ohm.york.ac.uk)

Department of Electronics  University of York

Heslington   YORK YO1 5DD U.K

Tel +44 (904) 433221   Fax +44 (904) 432335

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

On a completly different note - I've just aquired two teletext adapters. One is going home for normal use - we're planning to put the other onto our network (via BBC+serial line to an old microVax). We should be able to set it up so anyone can call in and request pages accross the internet :-) I 'll keep you informed.

Ian


Me!
Date: Wed, 20 Jan 93 14:48:08 GMT

From: u9105611@athmail1.causeway.qub.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: Me!

I'm not too sure if this is the right address to post this to, but I'll try it anyway!

I am Alan Meban.

u9105611@athmail1.causeway.qub.ac.uk

(which is a bit longwinded, so  u9105611@[143.117.254.4]  is a bit shorter)

For JANET folks a.meban@uk.ac.qub.v2 is sufficient.

Setup:

BBC Master 128K

Dual switchable 40/80T disk drive

Epson LQ550 24-pin printer

A crummy portable tv

My claim to fame is a selection of on-screen clocks, mostly working from sideways ROM - including a rather nice analogue clock that sits in the top right of the screen.

I'm at Queen's University in Belfast doing Maths & Computer Science. I spend most of my time using UNIX workstations ... so the old BBC is a bit neglected. If only C was shorter, or I could find a really cheap hard drive!

A nice word-processor that could drive a 24-pin printer in justified, proportional text mode would also be nice!


BBC on Desk!
Date: Thu, 21 Jan 93 14:37:45 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC on Desk!

I've finaly got it sorted that I've got a BBC on my desk here in the lab! (I'm writing this on it).

While this is completely superfluous as reguards dong any work, it does mean that I can transfer files really easily, and also try cross compile stuff.

(I promised to mail tcc+ some other stuff to Mathew - I'll do it now!)

Ian say Yey!


Please add me to the BBC mailing list
Date: Tue, 02 Feb 93 13:47:26 +0100

From: stjohn@poly.polytechnique.fr

To: bbc-list@ohm.york.ac.uk

Subject: Please add me to the BBC mailing list

Hi. Could you add me to the mailing list please?

I've not really got a BBC but rather a Cambridge Workstation. Nevertheless I'm looking around for good BBC software to run as well as trying to port an ANSI C compiler to Panos. Maybe eventually I'll write a better (multi-tasking) OS to replace Panos but for now I'm stuck with it. Anyway, 32k RAM, 32k Shadow, 32k Sideways when I can get 'round to soldering it in. 20Mb HD, 1Mb on the 32016 which will soon be running at 10MHz. Mail me if you've got a 32016 2nd processor as I'm looking for other owners to share information on hacking Pandora.


re:32016, (+Teletex stuff)
Date: Wed, 3 Feb 93 09:33:24 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: re:32016, (+Teletex stuff)

To my knowledge the 32016 users on the list are me (ian@ohm.york.ac.uk)and  Richard Whitehand <R.W.F.Whitehand1@lut.ac.uk>.

kierant@cogs.susx.ac.uk (Bobby McGee) is also on the list but his mail is has been bouncing for the last month or so.

"Bruce 'Loodvrij' Keeler" <csc228@central1.lancaster.ac.uk> also owns a 32016, though he's nopt on the list, and was trying to sell it last time I mailed him. It may still be on the market if anyone is interested.

If anyone else has a 32016 I'd also like to know about it!

GCC can target to 32000 - I got that to compile on my NeXT, but never sorted out the linking and libraries etc. The big problem would be the lack of a Pandora reference manual. I started work on a 32016 disassembler to hack into the code, but never used other than to debug it (which I didn't fin ish!). I can put this on ftp if anyone wants to try it.

I'd be interested in any development project to try and fix the worst piece of software that Acorn ever wrote!

On a completly different note, I (+the rest of the lab) aquired two teletext adapters a few days ago - One Morely, and one Acorn unit. Unfortunatly the Acorn only has TFS. This is particularly anoying as the Morley unit has ATS (which looks like Acorn's ATS but drives different hardware). Has an yone got a copy of the ATS ROM they could mail me?

Thanks

Ian Stephenson


Re: 32016, (+Teletex stuff)1
Date: Wed, 03 Feb 93 20:54:40 +0100

From: stjohn@poly.polytechnique.fr

To: I Stephenson <ian@ohm.york.ac.uk>

Subject: Re: 32016, (+Teletex stuff)

Do you know if the software that was brought out for Panos is more-or-less in the public domain? (ie. are Acorn likely to press piracy charges against people sharing what little software is around as it's no longer available?) I know a few people at Acorn so I'll try to get an unofficial answer. As soon as I have that then I'll happily send copies of Modula-2, ISO-Pascal, Cambridge LISP and the C compiler (though it's rather dodgy as you said) for limited distribution. Certainly quite a bit of the Pascal and C belong to NS who (I believe) distribute the languages for free to promote their processor.

Do you actually have the Norcroft compiler because that's ANSI draft conforming and would REALLY help. (in fact, I'd probably drop LCC if I had Norcroft instead). As for libraries, apart from using the existing C ones I dunno. How do you assemble the 32k code? GAS? ASM32?

There is also room for discussion on the Pandora images as I run on V2.0 whereas I believe others use V1. The actual Pandora system itself is incredibly small (about 3k I think) and it really is only an I/O support module. Initially I would try to build a multi-threaded OS on top of Panos (probably single-threading through Panos itself) in parallel with the development of low-level Pandora interface libraries. Otherwise nothing is going to get off the ground as the OS needs a decent compiler and a detailed knowledge of Pandora and the compiler needs a proper OS to support the libraries etc. A friend at Cambridge (Brian Brunswick, sometimes contributes to comp.acorn.xx) managed to write a true multi-treading kernel for the Arch which did more or less what I'd like to do with Panos so it IS possible.

I like your idea about Smalltalk. If it's just a HardDisk that's stopping you then I'll see how much in the way of spare parts my brother and I have (the controller is the biggest problem: we've got a spare SCSI/BBC interface and two spare ST506 drives but no Adaptec to put inbetween). Otherwise feel free to mail me the source or the FTP site I can get it from and I'll have a look at it.

Anyway, somehow I'll try to fit all this in with research and beer!

Chris


Hello everyone
Date: Thu, 4 Feb 93 11:05:27 GMT

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: Hello everyone

As I have just been added to the Beeb mailing list, I thought I'd let you know my hardware.

I have a Beeb with Solidisk 256k 4MHz board, 8271 & 1770, Music 5000, Star LC10, 6502 2nd proc and a 32016 2nd proc.

I also have a Master with a 6502 2nd proc., and lots of extra hardware such as eprom progger, etc.

The last bit is an A5000, which is why the former stuff is less used these days. Anyhow, I still prog. my Beeb and it is undoubtably the best machine for interfacing.

I see people are interested in the 32016s. Unfortunately I haven't had time to play with mine very much, and also due to the lack of a technical manual I have not done any programming on it. (Also the lack of a compatible ADFS makes matters worse. Anyone got one?)

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


languages, in particular COBOL
Date: Thu, 04 Feb 93 20:02:00 GMT

From: u9105611@athmail1.causeway.qub.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: languages, in particular COBOL

Hi there again

A couple of years ago, BBC Acorn User ran a version of COBOL (Small COBOL, I think). Does anyone out there have it that could email it to me (address below). I've just started a course in data processing & a COBOL compiler/interpreter/whatever would be very useful.

If anyone has any other languages I would also be interested. I have just started Ada ... the lecturer summarised the entire language in 1 hour ...... argh.

Thanx

Alan Meban

(I have a BBC Master & Dual drive)

Internet: u9105611@athmail1.causeway.qub.ac.uk

          u9105611@[143.117.254.4]     -- not everywhere finds here.

          af341@yfn.ysu.edu

   JANET: csg0017@uk.ac.qub.v2


Beebug 'C'
Date: Wed, 10 Feb 93 16:29:13 GMT

From: matthew@tadtec.co.uk (Matthew Sweet)

To: ian@ohm.york.ac.uk

Subject: Beebug 'C'

I now have a complete Beebug 'C' package, and can compile 'C'

source up to run on the BBC. It doesn't compile to 6502 code,

but to stuff called 'B' assembler that a virtual machine runs.

Now to try and get hold of a hard disk and a copy of gcc source...

(does gcc support 6502 as a target?)

Matthew

ps - how goes the teletext decoder bit?


Beebug C and other things...
Date: Wed, 10 Feb 93 17:36:51 GMT

From: matthew@tadtec.co.uk (Matthew Sweet)

To: ian@ohm.york.ac.uk

Subject: Beebug C and other things...

Ian,

I have a full set of official Documentation and so on for the Beebug C package, including the libraries and optional stand-alone code generator. (Thanks to an academic site that bought some PCs and therefore didn't need C for the BBC anymore.) Thanks for the offer.

Well done with the 32016 code. I hope that you iron the rest of the bugs out quickly.

I know that a single pass compiler is out of the question. I was thinking of a set of smaller routines that do the job in series. Are the other smaller compilers sources public domain? Would we be able to make any ported versions public domain?

>The teletext decoder both work fine. Unfortunatly, having collected all

>the hardware, I discovred that we can't get an arial feed in this lab! It

>should still be possible though by connecting it to a spider port

>somewhere else in te building.

Good. I am in the process of thinking about wiring the house up. I shall lay three co-ax lines everywhere (TV arial, cable, one for future expansion), and am thinking about what else would be a good idea. Has anyone done Ethernet for a BBC (half smiley)? I am not interested in Econet as it is Acorn Specific.

Matthew


Minor progress on Pandora...
Date: Sun, 14 Feb 93 01:01:13 +0100

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: ian@ohm.york.ac.uk

Subject: Minor progress on Pandora...

I too have now managed to persuade Pandora to do OSxxxx traps. I used TK_EXIT_PROGRAM (=17) to finish and that seems to boot the CLI okay. The linker is willing to link absolute code okay, though it will only accept references external to the current module if it deems them 'absolute'. So we can use JSR and JUMP to call from one file to another but not BR or BSR. More brain damage to come.... Can't _READ_ the CPU special registers 'cos I'm not in supervisor mode under Panos (!). Protection is okay, but that's downright paranoia!! Anyway, the long & short of it is that I still havn't found where the SVC traps to in Pandora. On UNIX, I'm working on getting a CPP ready for transportation to Panos. When I've done that, I can post-process NCC assembler output files so that they can be loaded as absolute images. (if you're wondering about all this absolute image support, checkout LINK -HELP and all will be revealed) I've started writing assembler device drivers. Next will be context switching. Malloc is already written but in C. I'll try to get started uploading Modula-2 but it really is a mamouth task.

Bed time!

Chris


32016 Compiler (+others)
Date: Mon, 15 Feb 93 14:33:15 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: 32016 Compiler (+others)

Traffic seems to be quite on here right now, but behind the scenes some of us are hacking furiously!

Those of you with 32016's may be pleased to know I've ALMOST got a cross compiler (GCC2.3.3) running from my UNIX box. There are still a few bugs to be fixed, but the basic stuff is up and runining - it uses Pandora rather than Panos so the end result should be a bit more stable than the existin g software. thanks to chris for support on this one.

Chatting to Mathew - he's been wondering about networking Beebs with other machines (CHEAPLY!!!). I'd also like to lay i some cabling to connect together my machines. Any ideas? How parctical would it be to implement a simple network based on multidrop serial cable - one cable with small interfa ces to convert them to rs232 where they can be handled by whateer hardware is available - rubbish performance, but good portability.

I just added mark to the list - for some reason he wants to rewrite adfs - I seem to remember a few messages from a few other people with similar ideas. Any volenteers?

Ian


32016 Compiler (+others)1
Date: Tue, 16 Feb 93 15:37:46 GMT

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: 32016 Compiler (+others)

> Those of you with 32016's may be pleased to know I've ALMOST got a cross

> compiler (GCC2.3.3) running from my UNIX box. There are still a few bugs

> to be fixed, but the basic stuff is up and runining - it uses Pandora

> rather than Panos so the end result should be a bit more stable than the

> existing software. thanks to chris for support on this one.

Certainly sounds nice. How about a cross assembler running on an ARM?

> together my machines. Any ideas? How parctical would it be to implement a

> simple network based on multidrop serial cable - one cable with small

> interfaces to convert them to rs232 where they can be handled by whateer

> hardware is available - rubbish performance, but good portability.

It really should not be hard. Depends how flexible it needs to be.

> I just added mark to the list - for some reason he wants to rewrite adfs -

> I seem to remember a few messages from a few other people with similar

> ideas. Any volenteers?

I know someone who has already done this. Its quite good, but not quite complete. Also a few bugs.

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Cheapo network
Date: Mon, 15 Feb 93 21:36:32 +0100

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: Cheapo network

Yeah. Multidrop networks on RS232 work 'cos I implemented a protocol called ModBus(tm) on a PC while working last summer. With suitable device handlers (ie. with fast interrupt capability) you can get full 19200 baud (though I think we needed coax cables :-)

The hardest bit (and most painful from a hobbyist point of view) is that the protocol assumed that one machine was dedicated to allocating bandwidth to the others. Fine if you have a spare beeb! A long time ago I designed a protocol (this was 5th year secondary...) which didn't need a master but instead the machines pass on a key around a ring. Trouble was that you had to reconfigure the network to add/subtract a machine. If anyone is interested in any of this, drop me a line and I'll describe more fully what I did.

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "In the beginning all was bottom. The Lord

                    said 'Cousot' and everything became top"

PS: still racking my brains about who the (tm) of ModBus belongs to. Gould rings a bell but I wouldn't put a beer on it. Anyway, here in France there isn't another user in a 200 mile radius so I think you can count me out on this one...


Re: Cheapo network
Date: Tue, 16 Feb 93 15:47:43 GMT

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: Re: Cheapo network

>

> Yeah. Multidrop networks on RS232 work 'cos I implemented a protocol called

> ModBus(tm) on a PC while working last summer. With suitable device handlers

> (ie. with fast interrupt capability) you can get full 19200 baud (though I

> think we needed coax cables :-)

Nah, your not trying! If you put a bit of effort in, you can get a full 76.8kbaud out of a Beeb, and you don't need coax cable unless you are going a LONG way. (15m normal cable works for me.)

Even the OS can do 19.2kb, JUST!

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Re: Cheapo network1
Date: Wed, 17 Feb 93 19:57:57 +0100

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: Re: Cheapo network

I agree that flat-out you can get very high bandwidth (though I must say I'm impressed that the olde wurlde tech. in the beebs can manage nearly 80Kbaud) The trouble is that if you start playing with that sort of speed in a network application you need a 100us interrupt cycle (remember that you're going to want to do something with the machine at the same time as being on the net!) you're doing well if you can get a 400us cycle out of a 6502 and even that will need a lot of bitdiddling if you're going to have a workable system.

As for coax, I would have thought that above about 10kbaud you're better off with screening. The company I was working for was Sollac, the largest steel production outfit in Europe. The net was supposed to work next to electric arc welders ;-) as it was to help control a steel rolling plant.

Anyway, somewhere I have all the sources for what I wrote. I'll try to dig 'em up. I would have thought that a cheap net would either be a Cambridge Rind style system or else a Cheaponet (in fact if you hunt around in old digi-electronics tutorial books they often have a cheap ethernet near the end. I think there are chips around but we're getting off the subject...) If the beeb ACIA can do simultaneous I/O (which I think it can as I remember testing mine by wiring out to in) then you have a chance of an ethernet protocol which is dead easy to code. Otherwise it's a ring system which is harder but not much.

Don't underestimate the speed problem. I was using a 486 at Sollac and we had to install special device drivers to get 95% efficiency (after framing & CRC) at 19k2. Does anyone know how Econet work(ed/s) ??

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "In the beginning all was bottom. The Lord

                    said 'Cousot' and everything became top"


Re: Cheapo network2
Date: Thu, 18 Feb 93 10:52:26 GMT

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: Re: Cheapo network

> I agree that flat-out you can get very high bandwidth (though I must say I'm

> impressed that the olde wurlde tech. in the beebs can manage nearly 80Kbaud)

> The trouble is that if you start playing with that sort of speed in a network

> application you need a 100us interrupt cycle (remember that you're going to

> want to do something with the machine at the same time as being on the net!)

> you're doing well if you can get a 400us cycle out of a 6502 and even that

> will need a lot of bitdiddling if you're going to have a workable system.

The high baud rates are not that hard to achieve. During actual file transfer you are not going to want to do anything else - filing systems don't multitask on the beeb. I've written a Viewdata bulletin board system which can pump menus out at over 40kbaud, and that is without doing anything silly like disabling interupts. Indeed, the reason I know the baud rate, is because the in & out baud rates are measured continuously to the nearest 25baud, and displayed on the scrolling bar at the bottom!

During the menu display, the screen is updated as normal, and the sysop can be busy doing other things with built in mouse controlled windowing type system! And we still get 40Kbaud.

> As for coax, I would have thought that above about 10kbaud you're better off

> with screening. The company I was working for was Sollac, the largest steel

> production outfit in Europe. The net was supposed to work next to electric

> arc welders ;-) as it was to help control a steel rolling plant.

For that application, I think I'd recommend coax, too. :-)

> If the beeb ACIA can do simultaneous I/O (which I think it can as I remember

> testing mine by wiring out to in) then you have a chance of an ethernet

Indeed it can.

> Don't underestimate the speed problem. I was using a 486 at Sollac and we

> had to install special device drivers to get 95% efficiency (after framing

> & CRC) at 19k2. Does anyone know how Econet work(ed/s) ??

Ah, well that's a pc. Its only to be expected. These baud rates are all achieveable - what I am saying is based on practical experience. The BBs is running 24hours a day...

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Zany idea
Date: Wed, 17 Feb 93 20:14:39 +0100

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: Zany idea

Okay. You're all going to say I'm mad but I don't care! 8-)

How about using the floppy disk controller for networking?

It has all the framing & CRC checks onboard as well as being able to wait for a certain sector (for sector read net address) to come 'round on the spinning disk. When it does it'll interrupt you and read the input through a buffer into the CPU. Most of the hard work (packets, CRC, framing, polling, address recognition, ana-digi conversion) is done for you. I think you can get about 10Kbytes/s out of a disk controller with a 10^13 bits per error correction ratio.

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "In the beginning all was bottom. The Lord

                    said 'Cousot' and everything became top"


Networks
Date: Mon, 22 Feb 93 18:04:12 GMT

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Networks

  Does anyone out there know the following

a) Whether you can buy the components for an Econet upgrade to a model B 'directly' as it were (ie not as a kit from Acorn)

b) how much it would cost to fit Econet to a Model B

c) whether this is difficult and requires special skills etc (ie am I likely to be able to manage it)

d) whether it would be easier/cheaper to get hold of a second hand B with Econet already in

  It's not that I'm planning to do this right now but I was thinking about some

things yesterday and this came up

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

Teach children to be polite and courteous in the home, and, when he

grows up, he will never be able to edge his car onto a freeway.


Re: Networks
Date: Wed, 10 Mar 93 21:31:44 GMT

From: Daniel G Shimmin <dgs%orion.physics@ox.ac.uk>

To: bbc-list-request@ohm.york.ac.uk (Mik Davis)

Subject: Re: Networks

>

> 	d) whether it would be easier/cheaper to get hold of a second hand B

> 	with Econet already in

My old school might have one or two, I will have to remember to ask them. If I haven't got back to within three months one way or the other, assume I've forgotten and ask me again.


tequilacomm4
Date: Tue, 23 Feb 1993 18:31:40 +1200

From: sainty_d@kosmos.wcc.govt.nz

To: BBC-LIST@OHM.YORK.AC.UK

Subject: tequilacomm

Almost 2 months ago I made the offer of distributing my comms program to individual people, but then mysteriously ( :-) disappeared from the modemming world! Sorry about that.

I'm now back, and intend to get onto this as rapidly as I can!

The people who wrote to me are:

daniel@yoyo.cc.monash.edu.au (Daniel Bowen)

matthew@tadtec.co.uk (Matthew Sweet)

zrzm0370@helpdesk.rus.uni-stuttgart.de (Joerg Scheurich)

A.Leahy@st.nepean.uws.edu.au (Andrew Leahy)

ian@ohm.york.ac.uk (I Stephenson)

rsteele@geog.canterbury.ac.nz (Robbie Steele)

Thankyou all. Anyone else wanting a copy can mail me too, especially if you tried to mail me and are not on this list (my account was purged due to inactivity! :-)

Other matters of interest:

I've upgraded my hard drive from 8 megs to 20 megs. The new drive however is about a quater of the age of the old drive (The old drive is about the same age as my old model B I think!), and has a track step time some 15 times faster than the old! Time for a modified version of ADFS to deal with this!

My HD boot program makes a copy of the (Master) ADFS rom into a sideways ram bank and modifies it, also adding some code to set up the hard drive specs every time break is pressed (My HD controller board defaults to the correct number of heads, but an incorrect number of cylinders).

This may be useless to all, as my setup is not quite Acorn specification (the SCSI->MFM controller board is a Seagate device, rather than Adaptec, and has head stepping options that may not even exist on the Adaptec board). It'll really be of most use to people trying to hack their own Hard Drive systems together.

Further to that, Acorn were kind enough to send me the technical details of their interface (1MHz -> SCSI), so if anyone needs the info on an ADFS compatable interface (ie. the circuit diagram) I have this here.

Dave.

(terros@sideways.welly.gen.nz)


Econet Printer servers
Date: Tue, 23 Feb 93 16:53:45 GMT

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Econet Printer servers

  Does anybody out there know anything about writing Econet printer server software. I've been looking at this recently and I thought of the following points:

1) I can pick up packets from the net and print them but

a) How much data is in each packet?

b) How do I know when I have the last one?

2) What do I do if another station requests service whilst I'm still servicing a previous request

3) Do I have to respond to a client doing a *PS command and if so, how?

  I did post a message asking about Econet printer servers on the net but all I got was a message from Acorn saying "You can buy one from us for 40 pounds".

    Mik  (the hopefull)

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

Lunatic Asylum: The place where optimism most flourishes.


Reading/writing DOS disks
Date: Sat, 13 Mar 93 22:17:03 +0300

From: DPetrov@misis.msk.su (Dimitry Petrov)

To: bbc-list@ohm.york.ac.uk

Subject: Reading/writing DOS disks

Hello!

(I am recently joined to the bbc-list and haven't yet received any information about its members)

I have a DOS filing system for BBC B+/Master.

It allows you to read/write standard 360K PC disks.

I had wrote it quite a long time ago with a little hope to sell it somebody in UK. After several years I understood that it is practically impossible (or it seems to be so).

Now, if anybody interested I could send you the DOSFS by e-mail.

Also I have some other utilities for Econet, RAM FS (RAM-disk).

I am interested in getting communication programs for BBC/Master (allowing 8-bit character set and X, Y, Zmodem or Kermit protocols).

Dmitry Petrov

student of Moscow State University

---

 DPetrov@misis.msk.su, DPetrov@misis.msk.su (Dimitry Petrov)

 Russian ARM Support Group


Re: Reading/writing DOS disks
Date: Sun, 14 Mar 93 15:10:26 GMT

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: DPetrov@misis.msk.su (Dimitry Petrov)

Subject: Re: Reading/writing DOS disks

> Hello!

Hi there!

> I have a DOS filing system for BBC B+/Master.

> It allows you to read/write standard 360K PC disks.

Great! I'm after one of those! Don't suppose it could be modified to do 3.5in 720k disks too?

> Now, if anybody interested I could send you the DOSFS by e-mail.

Oooooh, yes please...!

> I am interested in getting communication programs for BBC/Master

> (allowing 8-bit character set and X, Y, Zmodem or Kermit protocols).

I have a whole set of these on my bulletin board. Your best bet is the 'Aterm' series by Gareth Babb that do black&white ANSI or 4-colour ANSI terminal emulation, Xmodem, Xmodem-1k, Ymodem, Ymodem-batch and Ymodem-batch-g protocols...the terminal is pretty fast too...should keep up to at least 9600baud without problems... I don't think anyone has written Zmodem for the beeb yet...besides, if you've got a reliable link (eg an MNP modem) then Ymodem-batch-g is just as fast in most circumstances).

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Minimum configuration?
Date: Mon, 15 Mar 93 16:26:04 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Minimum configuration?

I just got given an issue 7 board, from which virtually ALL the components have been stripped.

Has anyone any idea what the ABSOLUTE minimum chip set needed to get a running system?

Obviosly I need a 6502, and I think I need a 6845 to do the memory refresh (they left the RAM in, as its all soldered).

I can obviously live without the model B stuff, but do I need all of the model A chipset? Can I live without a Video ULA (If I don't want video - though I probably do), a system 6522?(I don't want sound, and probably don't want a keyboard - I'll install a serial ULA, and use my current machine a s a keyboard).

I do remember that they don't power up without a keyboard, but figured that that was simply because the break key was on there (or some other simple fix).

The problem realy has wto parts to it, as I;m sure that most of the hardware I'll be dependant on will only be required if I run the MOS - how much more culd I get away with if I ditched that too (or patched it?).

I've a few ideas for things I could do with it - A second display would be nice. Failing that I could use it for a Teletext server.

It's pretty unfortunate that both the Video and Serial ULA's are missing as these will be hardest to get hold of. Anyone like to comment on my chances of getting this thing going? (Anyone got a pile of spare parts they're willing to part with?).

Ian Stephenson


Re: Minimum configuration?
Date: Mon, 15 Mar 93 19:52:10 GMT

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: ian@ohm.york.ac.uk (I Stephenson)

Subject: Re: Minimum configuration?

> Obviosly I need a 6502, and I think I need a 6845 to do the memory refresh

Definately.

> (they left the RAM in, as its all soldered).

Big deal!

> I can obviously live without the model B stuff, but do I need all of the

> model A chipset? Can I live without a Video ULA (If I don't want video -

> though I probably do), a system 6522?(I don't want sound, and probably don't

> want a keyboard - I'll install a serial ULA, and use my current machine as a

> keyboard).

I reckon it would be cheaper to get hold of a complete second hand board.

If you are gonna write your own os, you don't need a system via, but it would be recommended.

You might get away with a video ula, but I am by no means sure on this.

> I do remember that they don't power up without a keyboard, but figured that

> that was simply because the break key was on there (or some other simple

> fix).

I think not. The break key is just a make switch, so unless pressed you can't tell whether its there or not. I think it is the os getting upset. But then again, you're gonna write your own by the sounds of the above!

> The problem realy has wto parts to it, as I;m sure that most of the hardware

> I'll be dependant on will only be required if I run the MOS - how much more

> culd I get away with if I ditched that too (or patched it?).

Most of it. You definately need the cpu, 6845, (presumably the ttl stuff is still around, 'cause if its a bare board, I'd definately not bother), and possibly one or two other bits.

> I've a few ideas for things I could do with it - A second display would be

> nice. Failing that I could use it for a Teletext server.

Sounds like fun...

> It's pretty unfortunate that both the Video and Serial ULA's are missing as

> these will be hardest to get hold of. Anyone like to comment on my chances

> of getting this thing going? (Anyone got a pile of spare parts they're

> willing to part with?).

The ulas are kinda specialised. You might find an Acorn dealer with a couple of them lying around - do watford still sell them?

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Re: Minimum configuration?1
Date:         16 Mar 93 08:02:57 WET-2

From:         "Walter Meyer"  <WMEYER@scinet.up.ac.za>

To:           "I Stephenson" <ian@ohm.york.ac.uk>

Subject:      Re: Minimum configuration?

> Has anyone any idea what the ABSOLUTE minimum chip set needed to get a

> running system?

> Obviosly I need a 6502, and I think I need a 6845 to do the memory refresh

> (they left the RAM in, as its all soldered).

Yes.  Hopefully the ram works - if not, either the machine will not start, or you will see al kinds of interesting lines running vertically accross your screen

> I can obviously live without the model B stuff, but do I need all of the

> model A chipset? Can I live without a Video ULA (If I don't want video -

> though I probably do), a system 6522?(I don't want sound, and probably don't

> want a keyboard - I'll install a serial ULA, and use my current machine as a

> keyboard).

You'll need the video ULA (as it is used to divide the 16MHz clock from the crystal for the rest of the system).

Regarding the system 6522: I once built a "bbc-like" computer, with all the necessary hardware, except the ULA and the system 6522, with the hope that the OS would run (and that I could program it in basic).  However, it seems that the OS does not run if it can't see

the system 6522.  (If I remember correctly the ULA is mostly read- only, so most probably it will not be noticed.)

> I do remember that they don't power up without a keyboard, but figured that

> that was simply because the break key was on there (or some other simple

> fix).

I don't think it is that easy - see above.

> The problem really has wto parts to it, as I;m sure that most of the hardware

> I'll be dependant on will only be required if I run the MOS - how much more

> culd I get away with if I ditched that too (or patched it?).

I did that with the above card - disassembled the whole thing, and started implementing all the calls used by basic (I wrote a routine that prints out an error message every time an unimplemented OSByte/OsWord call is made).  I think I still have the assembler listing if you want it.

> I've a few ideas for things I could do with it - A second display would be

> nice. Failing that I could use it for a Teletext server.

>

> It's pretty unfortunate that both the Video and Serial ULA's are missing as

> these will be hardest to get hold of. Anyone like to comment on my chances

> of getting this thing going? (Anyone got a pile of spare parts they're

> willing to part with?).

The video ULA seems to be one of the most regularly replaced chip in BBC micro's.  (I would guess about 20% of all faults?)  I personally have five micro's that need new ULA's.  I have ordered some from Watford Electronics (who advertise having them) in December, but I havn't received any reply / goods yet.

Comparing prices in S.A., it seems that the ULA would be by far the most expensive chip.  The 6522's and the 6502 is relatively inexpensive.

> Ian Stephenson

Good luck

Walter

Walter Meyer

Department of Physics

University of Pretoria

South Africa

voice  (+27) (12) 420 3508

fax    (+27) (12) 43 6867

E-mail wmeyer@scinet.up.ac.za


Re:  Minimum configuration?2
Date: Tue, 16 Mar 93 08:38:46 GMT

From: David Alan Gilbert <gilbertd@cs.man.ac.uk>

To: ian@ohm.york.ac.uk

Subject: Re:  Minimum configuration?

You need at least the video ula because it does some clock munging, system via helps a hell of a lot (we had a machine with one missing and it got to basic - it just didnt do much else).

Dave


BBC Mailing list: intro
Date: Tue, 16 Mar 1993 10:36:10 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: BBC Mailing list: intro

Hi folks, I've just been added to this list and it was suggested that I send around an introduction, so here goes.  I'm not sure how much activity this list sees or what anyone else's general interests are, so I'm flying blind a bit.

As far as hardware goes, I've got a BBC B with single DS 80 track drive.  Might not seem much now but back in about 1986 that was a big deal!  I've also built one of the old Sideways RAM units described in an old A&B computing from around 1987 sometime which is real useful. Other things are fairly standard: Joystick (and Starstick chip). A Music 5000 & Music 4000 keyboard are fairly recent additions.

Now on to software & interests.  My brothers have heaps of games (some they bought; others typed from magazines), and I have a host of other utilities either written myself or typed from magazines. One time in the past I wrote a paper-delivery tracking system which I think is still in use in a few newsagencies around the place. I tried to get into games programming but didn't get too far with that :) Basically you can interest me with anything related to the BBC!

So why haven't I been on the list before?  Because I didn't know about it! Plus I had no way of connecting my BBC to the internet which meant I couldn't transfer programs or the like.

To conclude, if anyone wants to start a discussion or anything, I'll be only too pleased to hop on the bandwagon.

Bye for now,

Justin Ridge.

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


DOSFS now at shiraz.ohm.york.ac.uk
Date: Tue, 16 Mar 93 13:17:42 +0100

From: stjohn@poly.polytechnique.fr

To: bbc-list@ohm.york.ac.uk

Subject: DOSFS now at shiraz.ohm.york.ac.uk

Excerpt from README file in /pub/BBC/Submissions/dosfs.tar.Z

>       DOS FS  v. 1.13          (C) Petrov Software

>

>   Several years ago I wrote a  program  allowing  to  read/write

>360K PC disks  on  BBC B+. Several times  I  corrected some bugs,

>made improvements until  I  got an  access  to archimedes. Now  I

>stopped the  future development of the  code because I  failed to

>get any money for this program.

>

>   You could freely distribute the DOS FS as *SHAREWARE* product.

>If you'll like it and pay me a small registration fee I return to

>development of the program and you'll get free  upgrades. If not,

>you may use the DOS FS only two weeks.

>

> DPetrov@misis.msk.su (Dimitry Petrov)

> Russian ARM Support Group

Well it's on Shiraz now... I don't have any SRAM so I can't tell you what it's like. :(

If it's got garbled up then PLEASE mail me and I'll try to re-unpack the program from the UUENCODEd files.

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "When a banker jumps out of a window, jump

                   after him -- that's where the money is."

PS: Just like to plug that I've also just uploaded Bruce's Tools for Panos. Is there anybody out there actually using any of this stuff?? Still no feedback/bugs from DIS32 or SCPP... uEmacs is probably next, and I'm 800 lines (of machine code!) into a brand new kernel.


Re: DOSFS now at shiraz.ohm.york.ac.uk
Date: Tue, 16 Mar 93 13:24:21 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: DOSFS now at shiraz.ohm.york.ac.uk

I've just checked over the DOSfs stuff, and it looks pretty good (It's uploaded fine at least). I don't have a 1770, so its not much use to me, but if you've got a PC, and a 1770 I sugguest you try it.

I've moved Chris's version of the assembler into the 32016 directory. I haven't tried this either (as my Panos system is decidedly shakey). However the new kernel sounds very promising. I haven't done much work on 32016 GCC recently, but it now seems to be compiling properly (from a NeXT host). It's just the libraries that need debugged.

I don't know if this is of interest ot anyone, but I found a copy of the text editor TECO written in 6502. It's written for some obscure OS, but claims to be easy to port. If anyone feels like a go at converting it then I'll mail them the source - 5000 lines of assember! Whether you think this i s woth it or not obviously depends on whether you like TECO. If it was VI I'd do it myself.

Ian


Problems with Small-C on BBC B
Date: Thu, 18 Mar 1993 17:01:54 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: Problems with Small-C on BBC B

Hi everyone.  Last weekend I downloaded the Small-C package for the Beeb and tried to get it working.  Everything dehexed & decompacted with no errors, yet when I tried to compile one of the sample programs it fouled up.

The problem *appears* to be with the a65 section - it gives an error and aborts compilation.  The error is not very meaningful - apparently a few arbitrary characters from memory.

I encountered the same problem when I downloaded Small-C from another site and tried it on an arc with 6502 emulation.

My question is this:

Has anyone else gotten Small-C to work?

If so, is there any 'secret'?

Can you suggest anything for me to try?

And I might as well ask, how good is it when you DO get it running?

Thanks for any info,

Justin Ridge.

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


Re: Problems with Small-C on BBC B
Date: Thu, 18 Mar 93 13:12:41 GMT

From: "Mik Davis" <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Problems with Small-C on BBC B

>Hi everyone.  Last weekend I downloaded the Small-C package for the Beeb

>and tried to get it working.  Everything dehexed & decompacted with no

>errors, yet when I tried to compile one of the sample programs it fouled

>up.

>

>The problem *appears* to be with the a65 section - it gives an error and

>aborts compilation.  The error is not very meaningful - apparently a few

>arbitrary characters from memory.

>

>My question is this:

>Has anyone else gotten Small-C to work?

  I have it working

>If so, is there any 'secret'?

  I dunno, I got a fully de-compacted version from a PD library

>Can you suggest anything for me to try?

  I would suggest that you get in touch, send me a disk and I'll copy my version for you but you are rather a long way off :-)

>And I might as well ask, how good is it when you DO get it running?

  OK, so long as you don't want floating point numbers or mind having huge binaries (if you want to produce stand-alone code)

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

Whenever you find that you are on the side of the majority, it is time

to reform.

-- Mark Twain


Re: Problems with Small-C on BBC B1
Date: Wed, 28 Apr 93 21:16:43 BST

From: Daniel G Shimmin <@oxford.ac.uk:dgs@orion.physics>

To: bbc-list-request@ohm.york.ac.uk (Justin Ridge)

Subject: Re: Problems with Small-C on BBC B

Small C does work on the BBC B and Master 128.

My first copy was corrupted also.

I had a great enthusiasm for it to start with, 'cos it would do 16-bit integer multiplication very fast without me having to do any assembler (I'm hopeless).

However I am informed by people who (might) know that for serious programming it is very little use.

If you find out otherwise, let me know.


BBC network
Date: Thu, 18 Mar 93 09:38:52 +0100

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: BBC network

Hi. Just read this item on USENET. I remember a discussion about a cheap BBC network and this looks like it fit the bill. The actual post is about CP/M machines but then he talks about his network....

I"ve fairly heavily edited the original post....

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "Just because you're paranoid

                   Don't mean they're not after you" -- Nirvana

Article: 3901 of comp.os.cpm

Reply-To: ec_ind03@oswego.Oswego.EDU (William Jhun)

Organization: Instructional Computing Center, SUNY at Oswego, Oswego, NY

We are conducting an experiment which involves a parallel network at which data can be x-fered at high speeds. The process is quite simple. So far we have linked IBMs, Amigas, and Commodore 64s up to this experimental network. Between two lowly C64s, data can be transfered at around 32k/sec. Speeds will increase with faster computers.

The point of the project is to provide a useable network between a wide range of computers, large and small, with a minimal price tag.

The process is quite simple. Each computer requires an 8-bit (which should have handshaking lines, to add up to ~9 lines or more) bi-directional port (usually through a parallel port, where using a serial port faults on the RS-232s unusual -12/+12v signal, so we are trying to keep a moderate +5/0v TTL signal. The network will have 9-12 lines connected between each computer. 8-data, and other handshaking. The process to be proposed may need a little modification relating to the fact that if one computer crashes in the original design, the network chokes. The simple idea would be one computer sending a packet to another, with an ID header, etc, while that computer will bypass it to other computers if it is not the one receiving it. (this also leads to a big problem of security, but we have more advanced designs finished and pending)

William Jhun   (ec_ind03@oswego.edu)

|ec_ind03@oswego.edu            | while(flames--){FLAME[flames]='\0';|

|SUNY OSWEGO                    | SendFlame();} SendOneMoreFlame();  |

|William Jhun-P.O. BOX 346      | /\ FlameWar program by BTC and opt-|

|Minetto,NY 13115-0346 MBTI:INTJ|    imized by some guy named Craig. |


DOSFS again
Date: Thu, 18 Mar 93 13:31:22 +0300

From: DPetrov@misis.msk.su (Dimitry Petrov)

To: bbc-list@ohm.york.ac.uk

Subject: DOSFS again

Hello!

If anyone else interested in getting DOSFS and couldn't dounload it from SHIRAZ, please e-mail me.

Also, I am interested to know does anybody already used the DOSFS, and if not, what is a problem.

Dmitry

---

 DPetrov@misis.msk.su (Dimitry Petrov)

 Russian ARM Support Group


Smalltalk! (well almost!)
Date: Mon, 22 Mar 93 12:32:49 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Smalltalk! (well almost!)

Over the weekend I was playing with an interpretter for an almost smalltalk, running on Acornsoft ISO pascal!

Before you get too excited, I'll qualify that a little...

The system is a demo, taken from a book about languages and they're inmplementation. It takes a primitive language, and extends it to incorporate the interesting features of a number of real languages (lisp, ptolog, scheme, apl etc). The results are not realy that close to the languages they cla im to be, but have all the interesting features (the underlying syntax is that of the primative language which uses a prefix notation, so everything loos like lisp!).

I'm personaly interested  in the smalltalk version, as its very close to my favourite language Objective C. There are a number of problems with using this as anything other than a demo system - the worst being its use of memory - not so much a leak as a flood. In order to keep the interpreter si mple it makes NO atempt to reclaim memory. The book does however give a description of how to fix at least the worst of this.

Other than that the system lacks any interface to the OS, enumerated intance variables, messages to super, Class variables, and the treatment of Classes as first class objects (MetaClasses etc).

That sounds pretty negative, but the system does have most of the good bits - basically full class inheratance, and dynamic binding of objects. Most of the problems are either soluble, or not realy such a big deal anyway - I actually thing that the class definitions syntax is neater that real sm alltalk!

The interpreter is about 1000 lines of Pascal, and compiles to about 10K. It works fine on a co-processor, though I haven't tried it on an unexpended machine. Performance is adaquate for initial experiments, could be improved by optimising the evaluation stratagy.

I've placed the whole set of stuff on  shiraz called "kamim-c.tar.Z". If anyone out there is good at compiler internals, I think we could make something usefull from it.

Ian

P.S. I'm currently also hacking around a sound file player - unfortunatly I get hassle for testing it during working hours!


chip no longer needed
Date: Tue, 23 Mar 1993 11:47:58 +1200

From: Philip Michael Sainty <Philip.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: chip no longer needed

I just remembered that I'd mentioned earlier that I was looking for a replacement chip for my turbo board and forgot to tell people that my friend has found one for me, so if you were madly rushing about trying to find me one, you no longer need to :-)

Incidentally, does anybody know where I might find Doctorsoft's "Double Phantom" ??

We have two Masters linked together at home, so it would be great if I could get hold of this (only software needed) (I think)

While I'm on the subject, was Firebird's "3D Pool" ever released? I think they went out of business at about that time, but it looked well worth getting.

Finally, could somebody possibly send me a memory map for the turbo? I bought the computer 2nd hand, and the only documentation was the welcome guide and one of the reference manuals. (also, any other important or interesting stuff from the turbo info sheet would be appreciated)

big ':-)'s to anyone who can help,

Philip


ANSI-C??
Date: Tue, 23 Mar 93 10:51:39 +0100

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: ANSI-C??

I know a lot of you out there read Usenet too, but I thought I'd include this pointer.... comp.os.cpm, article 3917 (remember I posted an earlier article recently) is about a possible ANSI-C compiler for C64. Should generate 6502 code.... *gasp*

Well it's from the same guy as is doing the low cost parallel network, so maybe someone ought to mail him and ask about it. They expect to release the compiler in the Public Domain this summer.

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "Just because you're paranoid

                   Don't mean they're not after you" -- Nirvana

PS: After having to reformat my HD I found that I'd badly backed up edit6502-bbc. Can someone tell me what the load & exec address of the file is please (I think the load address is 2900 after disassembling it). A million thanks to the first person to mail me the correct answer!!


A new OS layer?
Date: Tue, 23 Mar 93 15:31:19 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: A new OS layer?

I've been thinking about what I get from my "REAL" computer systems Vs what I get from my BBC, and I think that the main problems (aside from lack of speed and memory :-)) could be solved by provision of a layer of code between user code, and the OS layer.

At its simplest I'm thinking of something that intercepts file opens/closes/reads and writes so that screen output can be redirected into a file, and keyboard input taken from a file. This is imply implemented by trapping all such calls, and then (for example) printing or writing the data as app ropriate.

A simple shell can then be built that sets up stdin and stdout prior to running the file. It could also test for files with a specific load/execution address (say 0000 0000 or ffff ffff) and treat those as scripts.

Programms would need to be writen so they use the new traps (though prehaps OSWRCH etc could also be interepted).

The ultimate extension of this would be to add relocation info to binaries so that they could be recursivly loaded (but that could be added later).

Anyone think that this is a good idea?

Is it worth developing (it requires a group commitment to produce software to run using the new layer)?

Ian


A new OS layer?1
Date: Sat, 27 Mar 93 17:42:15 +1300

From: David Sainty <terros@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: A new OS layer?

"I Stephenson" <ian@ohm.york.ac.uk> says:

>I've been thinking about what I get from my "REAL" computer systems Vs what

>I get from my BBC, and I think that the main problems (aside from lack of

>speed and memory :-)) could be solved by provision of a layer of code

>between user code, and the OS layer.

>

>At its simplest I'm thinking of something that intercepts file

>opens/closes/reads and writes so that screen output can be redirected into a

>file, and keyboard input taken from a file. This is imply implemented by

>trapping all such calls, and then (for example) printing or writing the data

>as appropriate.

But this is already supported through *spool/*exec more or less. Instead of adding to the OS new calls, at the very most patching onto the old ones will do the trick.

Perhaps via a *PIPE command, the necessary *spool/*exec commands can be executed, eg:

*pipe uudecode UUTequila | unzip

Something like this means no special versions of programs are required, and no special OS modifications need to be initialised before running said programs. What would need to be done is to build into *pipe information on where various programs get their input and output from, eg for the above, *pipe should know that it needs to call uudecode with UUTequila as an input, and a temporary file as output, and that Unzip requires an input file to be specified (which is the temporary file...) and will output a number of files.

Oh, well, that was a poor example of how *exec and *spool could be used, but you get the idea. Is this the sort of thing you are thinking of, or do you have something far more ambitious in mind?

Dave.


A new OS layer?2
Date: Mon, 29 Mar 93 10:30:26 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: A new OS layer?

>At its simplest I'm thinking of something that intercepts file

>opens/closes/reads and writes so that screen output can be redirected into

>file, and keyboard input taken from a file. This is imply implemented by

>trapping all such calls, and then (for example) printing or writing

>as appropriate.

>But this is already supported through *spool/*exec more or less. Instead of

adding to the OS new calls, at the very most patching onto the old ones will

do the trick.

The problem with *spool/exec is that they can't be used recusivly. A batch file can't contain another batch file for example. I agree that idealy it would be better to intercept the current OS vectors but that could get a bit messy. For now I want to keep things simple.

>What would need to be done is to build into *pipe information on where various programs get their input and output from.

UG :-(

>Oh, well, that was a poor example of how *exec and *spool could be used but

you get the idea. Is this the sort of thing you are thinking of, or do you

have something far more ambitious in mind?

This is part of the basic functionality that I want, on which more can be built. I've been spending an hour most nights for the last week trying stuff out (6502 hacking is fun - I haven't done any for ages!). The result so far is a CLI which will support comments, star commands, and recursive ba tch files. I have a file on disc called "ls" which contins the text

#Catalouge a disc

*cat

The program is in two parts - the shell and the OS layer which traps writes to channel 0, and redirects them to the screen (and simlarly for reads). Addig pipes and redirection to the shell is then easy.

I'm currently considering how to handle executables. Seeing as relocation is difficult, I'm considering dumping the running image to disc before loading the new image, and then retoring it afterwards. The problem with this is for compiled code which uses a stack in a distant part of memory from the main program.

Ian


Relocation of 6502 images
Date: Mon, 29 Mar 93 15:54:39 +0200

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: Relocation of 6502 images

>I'm currently considering how to handle executables. Seeing as

>relocation is difficult, I'm considering dumping the running image

>to disc before loading the new image, and then retoring it

>afterwards. The problem with this is for compiled code which uses a

>stack in a distant part of memory from the main program.

Is relocation really that difficult? You'd only have to relocate to the nearest page boundary, and you should be able to deduce the relocation purely from the instruction context in programs written in a neat style.

eg. (my 6502 is a little rusty - forgive me...)

LDA (&2a00),Y

should be relocated whereas

STA &72

should not.

I think the benifits of relocation (stacking executables and, who knows, maybe even lightweight threads(!)) outweigh the disadvantages.

If you're really against relocation, you could use SRAM to page programs into memory.... At worst, copy the image into a memory cache rather than writing to disk.......

Just my 10 centime's worth...

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_).

---------------    "Just because you're paranoid

                   Don't mean they're not after you" -- Nirvana


Re: Relocation of 6502 images1
Date: Tue, 30 Mar 93 10:00:09 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Relocation of 6502 images

>Is relocation really that difficult? You'd only have to relocate to the

>nearest page boundary, and you should be able to deduce the relocation

>purely from the instruction context in programs written in a neat style.

It's not realy that difficult if you build it into the assembler. It would then produce some sort of object file format which contains a list of bytes (roughly the top end of two byte parameters) which must have the programs start address added to them. The loader could then do these corrections

 (AMPLE does this when it loades modules).

It could be hacked into as65, but I'm currently just usng the Basic assembler.

>eg. (my 6502 is a little rusty - forgive me...)

>

>LDA (&2a00),Y

Thats an invalid instruction (I forgive you :-)).

>I think the benifits of relocation (stacking executables and, who knows,

>maybe even lightweight threads(!)) outweigh the disadvantages.

>

>If you're really against relocation, you could use SRAM to page programs

>into memory.... At worst, copy the image into a memory cache rather than

>writing to disk.......

I'm currently paging to disc (it ALMOST [ie sometimes :-)]works!). It's slow, but not imposably slow (kinda remanisent of VMS). This gives most of the advantages of relocation (stackable executables [just about working] - prehaps even processes, though the context switch would be too heavy right  now), plus every program gets about 60K of memory to use (if it needs it - I only page out whats actually been claimed).

I agree that paging to sideways RAM would be a vast improvement. This would reduce the context switch time dramatically. However at the moment I don't have a set of routines to do that (I've got ome RAM disc stuff, but that seems to have some bugs, and in anycase switching fime systems is a real bitch). Changing the paging to read from RAM should be pretty easy - I hope to have something releasabe in a week or so, and then prehaps someone can find the relevant code to slot in.

Ian

>Just my 10 centime's worth...

>

>  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

> /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

>(____/ (_/ (_/_).

>---------------    "Just because you're paranoid

>                   Don't mean they're not after you" -- Nirvana


Re: Relocation of 6502 images2
Date: Wed, 31 Mar 93 19:40:07 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: ian@ohm.york.ac.uk (I Stephenson)

Subject: Re: Relocation of 6502 images

Hi Ian,

> added to them. The loader could then do these corrections (AMPLE does this when

> it loades modules).

Can't remember if we discussed this before...but I have an ever-growing (several megabytes at least, currently) collection of AMPLE files (mostly PD) if you're at all interested.

How many other folk reading this have Music500/5000 systems?

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


broken ADFS floppys
Date: Wed, 31 Mar 93 12:41:31 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: broken ADFS floppys

Hi all,

It has been rather quiet around here recently.

I have an ADFS floppy disc which refuses to mount

due to an error 48 on :<drive>/000000.

Can anyone help with any hints as to what is wrong,

or what software I can use on a BBC B to try and

repair the damage? - I suspect that the free space

map has become corrupted somehow.

Thanks in advance,

Matthew

matthew@tadtec.co.uk


Re: broken ADFS floppys
Date: Wed, 31 Mar 93 23:10:32 +0400

From: DPetrov@misis.msk.su (Dimitry Petrov)

To: bbc-list@ohm.york.ac.uk

Subject: Re: broken ADFS floppys

matthew@tadtec.co.uk (Matthew Sweet) writes:

> It has been rather quiet around here recently.

> I have an ADFS floppy disc which refuses to mount

> due to an error 48 on :<drive>/000000.

>

> Can anyone help with any hints as to what is wrong,

> or what software I can use on a BBC B to try and

> repair the damage? - I suspect that the free space

> map has become corrupted somehow.

The simplest way is to do the following:

 1) Prepare a blank ADFS disk.

 2) Read sector 0 from the blank disk and write it to sector 0 of your disc

 3) Read sector 1 from the blank disk and write it to sector 1of your disc

 4) Then try to *MOUNT your disc and copy all files to the blank disc.

 5) Reformat your disc (because its free space maps became invalid)

If you got an error after *Mount again, you'll need a slightly more complicated actions to recover your data. Write me and I'll try to help.

To read/write  sectors you could use the disc  editor called ADFSED or write  your  own  program using OSWORD  &72  (if  I  remember the correct number). Please write if you need a more detailed information...

Regards,

  Dmitry

---

 DPetrov@misis.msk.su (Dimitry Petrov)

 Russian ARM Support Group


coprocessor memory map?
Date: Thu, 1 Apr 1993 15:28:31 +1200

From: Philip Michael Sainty <Philip.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: coprocessor memory map?

hello all,

nobody replied last time, but I'll try again (in optomistic mode!)

could anybody send me the memory map for the 65C102 'turbo' co-processor ??

things are a wee bit awkward with out it.

any other useful information about the 'turbo' would also be appreciated.

thanks,

Philip


Re: coprocessor memory map?
Date: Thu, 1 Apr 93 14:43:04 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: coprocessor memory map?

The Turbo shuold be the same as the standad 6502 C0-processor wihich has a pretty simple layout:

FFFF

Tube hardware

OS (RAM Copy)

F800

Free RAM

C000

RAM copy of Language

8000

Main User Mem

800

Language Workspace

400

OS workspace

000

If you use a Hi language it starts at B800.

Langauge workspace is used exactly as it would be on the host.

Page 0, 0-EE is not used by the OS (though it probably is by the language).

Page 1 - stack

2	Vectors

3	error messages

Ian Stephenson

P.S. I've got a music 5000, and would like to hear any good demo's that are around.


Re: coprocessor memory map?1
Date: Fri, 2 Apr 1993 11:29:25 +1200

From: Philip Michael Sainty <Philip.Sainty@comp.vuw.ac.nz>

To: ian@ohm.york.ac.uk

Subject: Re: coprocessor memory map?

thank you to those who sent me the info,

Philip


Teco ...
Date: Thu, 01 Apr 93 11:04:34 BST

From: u9105611@athmail1.causeway.qub.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: Teco ...

It's not often that I am defeatist, but sometimes it's just not worth pursuing something - for instance, TECO.

Having managed to assemble all ~5000 lines on source code, I have discovered that the object file was 21.6K long - and that's before I added any of the code necessary to allow it to work on a BBC - aaarrrrrrrgggggghhh..

Assuming the code was loaded in at &E00, and you had shadow memory, that leaves 6.8K of memory free - not including the extra bits needed to cope with file I/O etc.

Loading in at &1900 would leave just 4.1K free - probably not enough to code the file handling.

In theory, it could be made into a Language ROm - using workspace for its buffers etc ... but it would be a HUGE job.

If anyone else wants to try to get TECO up and running, a copy of Alan Phillips' (of pdsoft.lancs/kermit fame) ASSEMBLER is a must - though ADE's assembler would do. Split the source into files of ~800 lines each, and chain each one from the previous one ... with a few changes:

.BYTE => DFB

.WORD => DFW

=     => EQU

it assembles no problem ... except for the RAD40 bit and it would never run ...

Any comments, suggestions, etc, will be gratefully received - as will any documentation on TECO (the on-line help from your local mainframe would do nicely). Our VAX at Queen's has a TECO editor, but the help is dire ... it list about 6 commands - not including EX for EXIT.

If anyone could email me any more detail about the commands, I would be grateful - I am tempted to try using it on the VAX for a while. The 6502 version seems to include a huge variety of commands, but their function is often labelled in the source, nor is their function obvious from the code.

However, I suppose 'vi' could be coded ...

                                       ... sometime!

Alan Meban

----------

u9105611@athmail1.causeway.qub.ac.uk

        @[143.117.254.4]

af341@yfn.ysu.edu

a.meban@uk.ac.qub.v2      (JANET)


*RLOAD
Date: Thu, 01 Apr 93 15:48:41 +0100

From: Andrew <abs@ukc.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: *RLOAD

Could someone tell me what the '*RLOAD' command does ? It is used in the  bootstrap phase of Tiny C. I assume it is for the Aries shaddow RAM board, but I have this board and ROM (but no manual), and the command is not recognised.

Thank you,

Andrew

Andrew Smith

Computing Laboratory, University of Kent, Canterbury, KENT, CT2 7NF, UK


Re: *RLOAD
Date: Fri, 2 Apr 1993 09:27:57 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: Re: *RLOAD

>Could someone tell me what the '*RLOAD' command does ? It is used in the

>bootstrap phase of Tiny C. I assume it is for the Aries shaddow RAM board,

>but I have this board and ROM (but no manual), and the command is not

>recognised.

I understand that *RLOAD loaded a ROM image into sideways RAM. I don't have any of this Aries equipment, so I couldn't say if it is for Aries, or if not, what the equivalent command might be :-/

JR

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


Re: *RLOAD1
Date: Sat, 3 Apr 1993 13:31:11 +1300

From: <julian@bridge.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: *RLOAD

justin@tasman.cc.utas.edu.au (Justin Ridge) writes:

> I understand that *RLOAD loaded a ROM image into sideways RAM.

> I don't have any of this Aries equipment, so I couldn't say if it is for

> Aries, or if not, what the equivalent command might be :-/

I think *RLOAD is used for that purpose in a Solidisc 4Meg board - certainly the 32k version of it...

--

This is a witty quote.


editor blues
Date: Thu, 1 Apr 93 16:26:58 +0200

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: editor blues

Alan Meban writes:

> However, I suppose 'vi' could be coded ...

>                                       ... sometime!

Nope. I've been looking at the code for VI recently having dispaired at the crummy editor supplied on the 32016 comprocessor, and it's a BIG project at least 20000 lines of C.

Maybe a project to write a small _MINIMAL_ editor is in order......

I started one called Nano-Emacs a year or so ago but didn't even get as far as garbage collection :(

Any 3rd year CompScis out there looking for an end-of-year project???????

Chris.


Re: AMPLE files (was: Relocation of 6502 images)
Date: Thu, 1 Apr 1993 08:57:47 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: Re: AMPLE files (was: Relocation of 6502 images)

>Can't remember if we discussed this before...but I have an ever-growing

>(several megabytes at least, currently) collection of AMPLE files (mostly PD)

>if you're at all interested.

>

>How many other folk reading this have Music500/5000 systems?

If this was discussed before, it was before I joined the list :-)

I've acquired a Music 5000 & Music 4000 second-hand... I'm still coming to grips with getting the most out of it, but I would be very interested if anyone wants to distribute PD stuff!  Here in Oz we never had access to the Music City -type bbses that were in the UK.

PS. Small-C still doesn't work :(

Regards,

JR

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


Re: AMPLE files (was: Relocation of 6502 images)1
Date: Fri, 02 Apr 93 08:19:58 +1300

From: Pat Cain <patrick@sideways.welly.gen.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: AMPLE files (was: Relocation of 6502 images)1

justin@tasman.cc.utas.edu.au (Justin Ridge) writes:

> If this was discussed before, it was before I joined the list :-)

> I've acquired a Music 5000 & Music 4000 second-hand... I'm still coming to

> grips with getting the most out of it, but I would be very interested if

> anyone wants to distribute PD stuff!  Here in Oz we never had access to the

> Music City -type bbses that were in the UK.

I'm willing to distribute the Ample User Group discs I have -- I'll probably be breaking copyright, but I can't imagine there being much of a market for them now .. so as long as nobody complains :-)

Zipped and uuencoded sounds like the best method to me (there are unzip and uudecode programs for the BBC).


Re: AMPLE files
Date: Fri, 2 Apr 93 18:03:45 BST

From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

To: patrick@sideways.welly.gen.nz (Pat Cain)

Subject: Re: AMPLE files

>

> Zipped and uuencoded sounds like the best method to me (there are

> unzip and uudecode programs for the BBC).

>

There are? Let me at 'em! Where?! Where?!...

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


Re: AMPLE files1
Date: Sun, 4 Apr 1993 05:14:38 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: Re: AMPLE files

>> Zipped and uuencoded sounds like the best method to me (there are

>> unzip and uudecode programs for the BBC).

>

>There are? Let me at 'em! Where?! Where?!...

I have a BASIC uudecoder, which works fine but is rather slow.  I might rewrite it in assembler (its quite short) unless someone else has done it already.

Sainty's unzipper is nifty as it is :)

If anyone wants these I can send them across to you individually...

A hexer/dehexer also comes with Small-C.

While we're on the topic, does anyone have a uuENcoder?  And has anyone written a zipper?  The unzip documentation inferred that there isn't one.  Perhaps that can be my project for next weekend :)

Yours compress-edly,

JR

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


Re: AMPLE files (was: Relocation of 6502 images)2
Date: Sun, 4 Apr 1993 05:15:06 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list-request@ohm.york.ac.uk

Subject: Re: AMPLE files (was: Relocation of 6502 images)

>I'm willing to distribute the Ample User Group discs I have -- I'll

>probably be breaking copyright, but I can't imagine there being

>much of a market for them now .. so as long as nobody complains :-)

I'm willing to do likewise, although as I only just got hold of my Music

5000 I don't have much stuff.

  AMPLE Vibrations (David Reed)

  AMPLE Bytes Back (David Reed)

  Cosmix (Pilgrim Beart)

  Notes (Pilgrim Beart)

  Music City (Ian Guinan)

I think the Music City stuff was publicly available anyway.

>Zipped and uuencoded sounds like the best method to me (there are

>unzip and uudecode programs for the BBC).

Yup.

JR

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


BBC: How long does Copyright last?
Date: Sun, 4 Apr 1993 05:15:36 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: BBC: How long does Copyright last?

This message was prompted by what Pat Cain said regarding AMPLE albums. Where software is concerned, how long is copyright valid for, at least in your country?  I suspect it would apply indefinately here. This has struck me as being rather absurd.

I understand that copyright on music must be renewed every so often, or else it lapses and becomes public domain.  On the other hand,  copyright on a book does not.  Thus what happens if a books author dies, it is no longer in print, and the publisher has gone out of business?  Anyhow, I digress radically....

To get back to the original point, say I have a ROM.  Say it is some tool like EXROM by Beebug.  Of course, when it was released, it would have been illegal to make an image of that ROM and distribute it. But what about now?  For all I know stuck here in Tas, Beebug may have ceased to exist.  They most certainly wouldn't still be selling EXROM.  As I understand it, one of the main reasons for copyright legislation is to ensure that the author gets their deserved royalties.  But EXROM isn't being sold any more, they lose nothing if it were to be copied, right?  All copyright does in this case is to prevent diehards (like us) from coaxing the most from our beloved friends (the beebs). Thus my point is, copyright has virtually ceased to serve its main purpose in such cases.  And when it has ceased to serve its purpose, is it pertinant to consider it?

Food for thought, maybe.

Justin R.

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


Re: BBC: How long does Copyright last?
Date:     Tue, 6 Apr 93 17:27:44 MET DST

From:     Gerben 'P' Vos <gpvos@cs.vu.nl>

To:       The BBC mailing list <bbc-list@ohm.york.ac.uk>

Subject:  Re: BBC: How long does Copyright last?

On Sunday April 4, 1993 Justin Ridge wrote on bbc-list:

>This message was prompted by what Pat Cain said regarding AMPLE albums.

>Where software is concerned, how long is copyright valid for, at least in

>your country?  I suspect it would apply indefinately here.

>This has struck me as being rather absurd.

Usually, copyright lasts for 50 years after the death of the author.

I don't know when it ceases if it is held by a company, i suppose it also lapses after 50 years or so. I'm not sure how renewing a copyright works, as far as i know it isn't really possible.

Greetings,

<>< Gerben.


Re: BBC: How long does Copyright last?1
Date: Wed, 7 Apr 93 11:56:18 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: The BBC mailing list <bbc-list@ohm.york.ac.uk>

Subject: Re: BBC: How long does Copyright last?

I'd agree that all BBC software is still under copyright and will continue to be for the forseeable future except were it has been explicitly relinquieshed.

However it may be possible to persuede the copyright holders that they really want to relax their hold on software, as it is no longer commercialy viable for them to distribute.

Acorn for example recently gave away a number of 6502 co-processors. This is clearly an indication that they no longer consider the BBC as a valid product line. If anyone has the right contacts it may be possible to get some form of agreement allowing the non-commercial distribution of some or all of their software.

Prehaps some companies would be interested in some sort of shareware deal (it doesn't cost them, and they MAY get something back).

A number of BBC products are still commerically available so its certainly not legit to make any global assumptions about the copying of software (at least not in public ;-)). However if anyone has any good contacts within software companies, obtaining a disclaimer would open up a lot of software that's no longer available, to a lot of people who would still find it usefull.

Ian


UUencode & archivers
Date:     Tue, 6 Apr 93 17:54:29 MET DST

From:     Gerben 'P' Vos <gpvos@cs.vu.nl>

To:       The BBC mailing list <bbc-list@ohm.york.ac.uk>

Subject:  UUencode & archivers

On Sunday April 4, 1993 Justin Ridge wrote on bbc-list:

>I have a BASIC uudecoder, which works fine but is rather slow.  I might

>rewrite it in assembler (its quite short) unless someone else has done it

>already.

>Sainty's unzipper is nifty as it is :)

>While we're on the topic, does anyone have a uuENcoder?  And has anyone

>written a zipper?  The unzip documentation inferred that there isn't one.

>Perhaps that can be my project for next weekend :)

I have written both a uuencoder and a uudecoder. I also have versions of both Arc and Xarc (archiver and extracter), which are ported by Bart Bruns. Arc has a nasty bug though (chops off the last x bytes of the archive).

You can find them on shiraz as uucode-arc ; you should be able to decode that file on your BBC, since it is in fact a bootstrap for the complete package, which i originally made for comp.binaries.acorn .

Greetings,

<>< Gerben.


Admin+Alpha software Release
Date: Wed, 14 Apr 93 16:07:49 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Admin+Alpha software Release

First off - there have been a few problems with our mail over the last few days, but they seem to be fixed now.

OK now the main bussines:

I've placed an Alpha release of my shell and OS layer software on shiraz(os-uue - its uuencoded and arced[Gerben's progs for this are excellent]). I've mentioned this a few times over the last few weeks, but now it really exists, and I'd like to get some feedback/distribute the development load.

As stands the code is a bit of a mess, but it does work and provides stacking of executables, and redirection of io. There's a library of routines which load in at C000 (its compiled for 6502 co-processor, but I did get it running on the host several times during development). Theses are started up by *OS. This loads in the file "sh" and starts it running. From here you can execute other  programs, and redirect their io (via > and <). This includes sub-shells, so shell scripts are supported (though currently shell variables and control flow aren't implemented).

The suplied programs are sh, ls (a shell script which calls *cat so can't be  redirected), hello (prints hello world), cat (prints the contents of a SINGLE file), and echo (prints its arguments). These are just about enough to demonstrate that a fully working system would be usefull (which is the purpose of this release - don't think anyone is meant to actually use it!).

As discusses previously its pretty slow (as it pages to floppy), but RAM disc or hard disc support would make things a lot faster. Lots of work is needed (a  complete rewrite of shell, and some sort of standard library interface), but I'd like to take this further. Hence this release - If anyones interested we can discuss what needs doing, and who can do it.

On a seperate but related note - is anyone using BCPL? I've got the source for a BCPL compiler, targeting to INTCODE if anyone is interested in trying it - it  shoud be binary compatible with the Acorn system (probably the same code!).  With a little work by someone ho understands this stuff we could have a PD BCPL  compiler up and running. (I've also get the source to a simlarly interpreted pascal compiler if anyone wants a go at that...).

Ian


Re: A new OS layer?
Date: Mon, 19 Apr 93 01:05:32 +1200

From: David Sainty <terros@sideways.welly.gen.nz>

To: I Stephenson <ian@ohm.york.ac.uk>

Subject: Re: A new OS layer?

"I Stephenson" <ian@ohm.york.ac.uk> writes:

> I spent quite a while a few years ago writing a multitasking system which use

> sideways ram to hold the images - each image was limited to 16K, but each cou

> then be assembled to run at the same location (0x8000), and was protected fro

> messing with the others data. A 6522 interupt switched between the currently

> active images.

>

> What I had worked fine, but in the end it just got too messy. The problem was

> ensuring that critical routines weren't interupted - in particular most of th

> OS routines re-enable interupts, and hence couldn't be called directly from t

> images.

Did you try using the PC at interrupt to check whether it was in an OS routine or not? I was thinking about process suspension, in particular being able to suspend a current process and then set it running in the 2nd processor in the background. This is the way I was considering ensuring OS and filing calls didn't clash.

> I'll probably release the stuff before this work is done so I get some feedba

> (I don't realy fancy rewriting the shell myself in any case :-). Despite the

> above warnings it does actually work! It feels sluggish due to the swapping,

> but I've certainly used worse. Being able to write scripts, and redirect outp

> is definatly worth the wait.

It'll be interesting to see!

As you've gone the way of needing to write from scratch any utilities you intend to use, why not make the program inform the system of memory requirements etc. Then just store the process information and program in main memory if it's free. Much faster than disc access. The other one is: support relocation! Make it mandatory that a program can be relocated, either by a built in routine in the program, or perhaps a file with a list of offsets into the programto add the program start page to.


Re: A new OS layer?1
Date: Mon, 19 Apr 93 01:21:21 +1200

From: David Sainty <terros@sideways.welly.gen.nz>

To: I Stephenson <ian@ohm.york.ac.uk>

Subject: Re: A new OS layer?

"I Stephenson" <ian@ohm.york.ac.uk> writes:

> I've put a uuencoded, Arced version of the code on shiraz in the BBC/submisio > directory - you may like to have a play with it (if you haven't got

> uuencode/arc then they're also in submisioins).

I'll attempt to get it today. Ftp is a little tricky.

> P.S. The machine which sends out the mailing list is playing up, so messages

> aren't currently going out. I'll make some anouncement on the list about this > code once everything's going.

Talking about the list, could you change my list address to:

dsainty@comp.vuw.ac.nz

This account gets read more often these days as varsity work piles on! Also,

it dosen't cost me anything! :-)


BBC mailing list?
Date: Wed, 21 Apr 93 10:55:41 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: BBC mailing list?

>From: I Stephenson <ian@ohm.york.ac.uk>

>

>I've added you to the list.

Thanks.

>I'm currently trying to get a project off the ground to provide a decent shell

>environment, which is going to require a team effort on behalf of the list so

>if you could do some coding for that :-)

I've thought about this too. I normally run in my own CLI mode (part of the Assembler/Disassembler ROM), which is really just an OSCLI dispatch loop. I'm (slowly) writing a new version of the Assembler, which will be much more advanced, and I've tried to make it possible for programs called via OSCLI to return status to the command line. This means that you can implement forward conditionals (i.e. if/then/else) as separate programs which take a test, execute it, and scan for the then or else clause. Loops are more complicated, because you have to save the loop body (which could be done by saving a file pointer and handle into the current *exec file, and disallowing loops from non-seekable input (i.e. keyboard). I'd like to have the shell level able to execute arbitrary programs rather than just ones written for it, within limitations. This may mean implementing a swapping system to page out the used memory in between program execution, in which case the shell should include as many built-in commands as possible, to reduce swapping. Or it may mean requiring the shell to run from Sideways RAM. Or...

>Check out the ftp site (shiraz.ohm.york.ac.uk), and you'll find a copy of the

>source to what I've done so far (the file is called something like oslayer-uue,

>and its uuencodeed and arced - bbc - decoders are also on shiraz).

I'll have a look.

a.

--

Angus Duggan, Department of Computer Science,	| Jobless, Phdless, clueless

University of Edinburgh, The King's Buildings,  | PHONE: +44(0)31 650 5126

Mayfield Road, Edinburgh EH9 3JZ, Scotland.	| INET: ajcd@dcs.ed.ac.uk


The big 4 0 !
Date: Wed, 21 Apr 93 10:53:13 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: The big 4 0 !

There are now 40 users on the BBC list :-)

The latest is Angus Duggan (ajcd@dcs.edinburgh.ac.uk) who sent the folloing  resume:

>BBC Model B series 7, 65C02 second processor (Tube), 80K SWRam on modified

ATPL board, 2x80 track floppy discs using 8271 controller and my own hierarchical DFS (with advanced Tube support, utilities and Acorn compatibility built in), AMX compatible mouse, Mono monitor, own Assembler/Disassembler, Music 500/5000. Quite a lot of software/ROM Images/etc.  Write most of my own programs in assembler, including a major re-write of Elite (you can buy new ships, take courier missions, ship configurations/speeds/armour/manouvreability are all different, on-line encyclopaedia, 6502 Tube support, replaced cop out features, much harder...). Don't use it a lot now, but if I can get a Music 4000 keyboard and other expansions at reasonable prices, I'll probably resurrect it.

There's some cool stuff in there - I'd like to hear more about this

hierarchical DFS...

On a completly different tack - I'm now 80% of the way to a working BCPL system  thats completly free of proprietry code. Last night it ran a factorial program  from start to finished, and printed out the right answers without generating any errors :-). The only stuff left to do is add the file handling routines, fix some endian-ness problems, and rewrite the comparison routines to work with  signed ints.

It actually pisses me of a little that Acorn had the nerve to charge so much for BCPL, as the product they sold is almost identical to the one I've  developed, and its taken me about two days so far! I suspect that Acorns will  run a little faster than mine does (better optimisation), and the libraries will be a little more complete in a professional product, but the compiler is  going to be THE SAME CODE! Acorn could have shipped it free with all machines,  and still made a profit on it!

For those who haven't seen BCPL, it's a lot like C but without any types, and  with a number of familiar extensions (that found there way into other languages  like BBC Basic and Occam!). I think its probably better than small C, though not as good as a full C compiler would be (but then again I've got the source,  so it could be developed).

Ian


BBC Master + 2nd processor
Date: Thu, 22 Apr 93 09:30:50 BST

From: Chris Robey <CJR1@ibm-b.rutherford.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC Master + 2nd processor

Hello,

I have recently bought a BBC Master and I am thinking about trying to expand it. I have heard about various 2nd processors but the one that sounds the

most interesting is the 6502C (i think thats what its called) because it makes the BBC slightly PC compatible.

Could someone please give a a list of the features of the 6502C and more importantly where I could lay my hands on one? (I gather Acorn have stopped making them).

Any help would be much appreciated.

Cheers - Chris


BBC Master + 2nd processor1
Date: Thu, 22 Apr 93 22:02:13 BST

From: RWF Whitehand <R.W.F.Whitehand1@loughborough.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC Master + 2nd processor

>

> I have recently bought a BBC Master and I am thinking about trying to expand

> it. I have heard about various 2nd processors but the one that sounds the

> most interesting is the 6502C (i think thats what its called) because it makes > the BBC slightly PC compatible.

The co-processor that makes the BBC somewhat PC compatible is the '512 board' (which uses an 80186 processor) and Norton SI claims its about 5 times the speed of the original IBM PC/XT thing. The 6502 2nd processor is simply a faster version of the processor already in the beeb/master with another 64k of RAM. Theres also a co-processor board (co-processors go inside the master, 2nd processors are attached outside) which is the 65C102...this goes slightly faster than the 6502 2nd proc as its clocked at 4Mhz instead of 3.

If you want to go really over-board then there are a few 32016 2nd processors (Acorn never sold the 32016 co-processor) around (rather rare/still quite expensive) that'll give your beeb some serious, erm, Ummmf.

> Could someone please give a a list of the features of the 6502C and more

> importantly where I could lay my hands on one? (I gather Acorn have stopped

> making them).

The second hand market is quite rich in 6502 2nd processors, 65C102 and M512 co-processors. Check out Micro Mart, etc. You shouldn't be spending more than 50quid, with perhaps a little more on an M512 board (it comes with a mouse and other bits and pieces).

> Any help would be much appreciated.

>

> Cheers - Chris

>

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


SuperBEEB
Date: Thu, 22 Apr 1993 10:24:01 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: SuperBEEB

Hardware hackers out there... I have a plan!

I want to beef up my BBC a bit. This depends on finding a FAST 65C02. I believe they run up to about the 10MHz range, so this is what I'm really looking for.

Assuming I find a source, here's some ideas:

Either:

pull the old 65c12 off the motherboard, plug in the new on a board with fast ram, and clock the new processor down to 2MHz to access the original hardware.

This gives a carbon copy of the BBC, but it does things.... faster!

Of course, it'll cost a BBC if anything goes wrong.

Second idea:

External processor, fast 65c02 hooked to a memory controller (the MEMC so loved by archimedes users may do this job, it'd probably be the cheapest) and about a meg of memory (cheap in SIMM cards these days).

This one is great! Can emulate multiple complete BBC's! Could even run it as a multi-user workstation!

I think a third processor will be required to deal with the MEMC page faults, the problem being that the 6502 when interrupted completes the current instruction, but what we really want to do is halt the instruction, deal with the page fault (a page fault here may mean an access to &FE00, so we need to emulate the hardware either by reading/writing to hardware on the BBC motherboard, or making note that that BBC image has altered that hardware register) and restart the instruction. alternatives are to use the old BBC processor for this job (which means it'll have less time to pretend being one of the BBC images, screen updates etc), or perhaps step back an instruction in software with hardware support (Say, keep a hardware copy of the last instruction address, on page fault read the instruction that caused it and reverse it if needs be. Most instructions won't need reversing, but instructions like ROR will).

Actually, that last method will probably be the best, but that's not a big job, so that's ok.

BBC<-->SuperBEEB communication I'm not sure about. In actual fact, the best option would seem to be to cut out the old 6502 and interface our baby directly to the bus, but assuming you want to keep the original functional by itself through all this, I guess a small memory transfer program is what's wanted, so SuperBEEB can say 'write here' or 'read here' type thing. And the original BBC should probably stick to doing the file handling by itself.

This is all pretty ambitious of course! But the end result would be a pretty serious machine! Are people interested in following up these (sketchy) ideas? Anybody got ideas of their own on this? Anybody ever HEARD of anyone interfacing a true memory manager to a 6502 before?

Dave.


Re: SuperBEEB
Date: Fri, 23 Apr 1993 12:50:33 +1000

To: bbc-list-request@ohm.york.ac.uk

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

Subject: Re: SuperBEEB

>Hardware hackers out there... I have a plan!

Phew, it seems that you have several.  I haven't looked through all of them yet.

>I want to beef up my BBC a bit. This depends on finding a FAST 65C02. I believe >they run up to about the 10MHz range, so this is what I'm really looking for.

>

>Assuming I find a source, here's some ideas:

The source could be a problem.  Rockwell make 4MHz 6502's - that is the fastest 'off the shelf' one that you can get.  A 10MHz 6502 design exists, but not as an individual chip - i.e. if you're building your own custom IC, and want a processor on it, you can get the 10MHz 6502 and connect it in, but you can't get an 'off-the-shelf' 10MHz 6502 processor.  The 10MHz 6502 was used in the Macintosh IIfx as part of its serial port setup - so if you can find a IIfx you might be able to strip it ;-)

[This info comes from our Technician so don't ask me hard questions :) ]

JR

--------------------------------------------------------------------------

Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


SuperBEEB1
Date: Sun, 25 Apr 1993 00:30:39 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: DPetrov@misis.msk.su

Subject: SuperBEEB

>It sounds surprisingly but here (in Russia) some company sells

>65C12/6502C compatible chips (pin compatible too!). This is a CMOS

>version (<0.005 Watt at 2MHz) and it could be run at MORE THAN

>15MHZ (!) but requires additional voltage for that (up to 15 V).

>I think its price is several times lower then  UK or NZ prices.

>If you are interested I could try to get concrete details as I have

>good contacts with the company...

Wow! I've had poor success here finding a source, I'd be extremely interested in hearing more about this!

Because of the poor results here, I was thinking another path to take could be an ARM board. With no software emulation of hardware to do, could get a very fast 6502 emulation running, and on top of that run some ARM stuff, probably even get a C compiler running in that environment.... (I know there's a command line C compiler for the Archimedes...)


Re: SuperBEEB1
Date: Mon, 26 Apr 93 9:54:38 BST

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: Re: SuperBEEB

> >15MHZ (!) but requires additional voltage for that (up to 15 V).

> >I think its price is several times lower then  UK or NZ prices.

> >If you are interested I could try to get concrete details as I have

> >good contacts with the company...

If those 6502s can be got reasonably cheaply I'd be interested...

> Wow! I've had poor success here finding a source, I'd be extremely interested > in hearing more about this!

I thought you might - I have never seen them around.

> Because of the poor results here, I was thinking another path to take could

> be an ARM board. With no software emulation of hardware to do, could get

> a very fast 6502 emulation running, and on top of that run some ARM stuff,

If you've got an ARM, I wouldn't bother emulating a 6502 - you would have a job getting it up to speed. Just use it native - there's plenty of Arc stuff around, & I bet a fair bit could be botched onto one of these. There must be tons of unused ARM2s about after everyone has upgraded to the ARM3. If anyone knows of any lonely ARM processors I'd be interested...

If you can get a 10-15MHz 65C02 I reckon by far the best bit is to soup up a second processor like someone else wants to do. Sod messing around with hardware emulation - after all, you don't really want to play Exile at mach 3 do you?? A fair bit of stuff (esp. useful stuff) will already work over the tube. I haven't looked in detail at turbo-charging a second processor, but I reckon it would be relatively easy. (esp. compared to doing it direct to a Beeb!)

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Re: SuperBEEB2
Date: Sat, 24 Apr 93 00:49:20 +0400

From: DPetrov@misis.msk.su (Dimitry Petrov)

To: bbc-list@ohm.york.ac.uk

Subject: Re: SuperBEEB

David Andrew Sainty <David.Sainty@comp.vuw.ac.nz> writes:

> Hardware hackers out there... I have a plan!

>

> I want to beef up my BBC a bit. This depends on finding a FAST 65C02. I belie

 > they run up to about the 10MHz range, so this is what I'm really looking for.

It sounds surprisingly but here (in Russia) some company sells 65C12/6502C compatible chips (pin compatible too!). This is a CMOS version (<0.005 Watt at 2MHz) and it could be run at MORE THAN 15MHZ (!) but requires additional voltage for that (up to 15 V).

I think its price is several times lower then UK or NZ prices.

If you are interested I could try to get concrete details as I have good contacts with the company...

Best wishes,

  Dmitry

---

 DPetrov@misis.msk.su (Dimitry Petrov)

 Russian ARM Support Group


BBC Master + 2nd processor2
Date: Fri, 23 Apr 1993 02:29:05 +0100 (BST)

From: Nicolai E.M. Plum <maufr@csv.warwick.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC Master + 2nd processor

I've been thinking of speeding up a 2nd processor (project now delayed until the next holidays, unfortunately) and got to thinking what I'd have to upgrade. I am talking about the external boxed type of 2nd proc., so there's little risk of it taking my Master with it to the next world if something goes wrong :-)

My main question is, can I just change the processor and the memory for faster versions, and hope the rest copes, or do I need to change anything else? If the glue logic is not man enough for the job that's easy to cure, but I sense a problem with the UART. If anyone has any specs for the beast I'd like to know its max. ratings. It already has a heatsink on it because it got far too hot to touch (for long)!

Nicolai


Equivalent for 8271 FDC?
Date: 5 May 93 07:27:45 WET-2

From: Walter Meyer <WMEYER@scinet.up.ac.za>

To: bbc-list@ohm.york.ac.uk

Subject: Equivalent for 8271 FDC?

A local school has a number of BBC model B's with Amcom DFS's (using the 8271 FDC from Intel).  Recently one of the FDC chips blew.  Since they would like to keep the BBC's as similar as possible, and also continue to use their Amcom's DFS disks (which seem to be incompatible with anything else), they are not keen to upgrade to a 1770 DFS.

I understand the 8271 is no longer manufactured by Intel, but, according to the local Intel agents, an equivalent is manufactured by NEC under a different part number.  Does anybody know what this part number is or wether it or any equivalent by another manufacturer exists?

Any help would be appreciated

Walter

Walter Meyer (wmeyer@scinet.up.ac.za)

Department of Physics, University of Pretoria, South Africa


Re: Equivalent for 8271 FDC?yes
Date: Wed, 12 May 93 21:51:12 BST

From: Daniel G Shimmin <@oxford.ac.uk:dgs@orion.physics>

To: bbc-list-request@ohm.york.ac.uk (Walter Meyer)

Subject: Re: Equivalent for 8271 FDC?yes

> A Local School Has A Number Of Bbc Model B's With Amcom Dfs's

> (Using The 8271 Fdc From Intel).  Recently One Of The Fdc Chips

> Blew.  Since They Would Like To Keep The Bbc's As Similar As Possible,

> And Also Continue To Use Their Amcom's Dfs Disks (Which Seem To Be

> Incompatible With Anything Else), They Are Not Keen To Upgrade To A

> 1770 Dfs.

I Think A Friend Of Mine Wrote A "Amcom Dfs > Standard Dfs Transfer Utility",

With A Variety Of Options. Would This Be Of Any Help?

> I Understand The 8271 Is No Longer Manufactured By Intel, But,

> According To The Local Intel Agents, An Equivalent Is Manufactured By

> Nec Under A Different Part Number.  Does Anybody Know What This Part

> Number Is Or Wether It Or Any Equivalent By Another Manufacturer

> Exists?

I'm Sure I've Seen Adverts In Acorn-Related Magazines (Acorn User, Acorn Computing Etc.) Including 8271 Chips. (?)

Daniel Shimmin, Queen's College, Oxford


A new thing...
Date: Wed, 12 May 1993 17:30:16 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: A new thing...

After reviving an old project, I hit upon the solution (made easier by the fact I now have a master with shadow ram, and didn't before). I've successfully doubled the vertical resolution of the bitmapped screen modes, giving a maximum of 640x512 in mode 0.

Having done this, I haven't any idea what to do with it! :-)

The refresh rate is effectively halved, which seems to be too slow to stop a certain amount of flicker under the wrong conditions (isolated pixels flicker). But it's not bad. Text looks good.

Anyone got any ideas for this?

On a different subject, a new version of unzip should be ready soon which handles the new zip algorithm, has some extra features, and fixes the bug that selective unzip NEVER works on the old version! (Anyone notice that _slight_ bug? :-)

After unzip, my next job is working on tequilacomm, on which I intend to support V.42bis and MNP2 in software, and support V.42 error correction with some additional hardware (The circuit for which will be reasonably simple so not too dificult to build, and will probably sit on the 1MHz bus).

If you already have an error correcting modem, V.42bis should sit happilly on top of that without requiring the additional hardware.

Feedback on any of the above will be appreciated (especially how many people would actually find the error correction/compression modem protocol stuff useful, so I know I'm not just doing it for myself! :-)

Dave.


Re: A new thing...
Date: Wed, 12 May 93 10:31:43 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: A new thing...

>After reviving an old project, I hit upon the solution (made easier by the

>fact I now have a master with shadow ram, and didn't before). I've  >successfully

>doubled the vertical resolution of the bitmapped screen modes, giving a

>maximum of 640x512 in mode 0.

>

>Having done this, I haven't any idea what to do with it! :-)

>

>The refresh rate is effectively halved, which seems to be too slow to stop a >certain amount of flicker under the wrong conditions (isolated pixels

>flicker). But it's not bad. Text looks good.

>

>Anyone got any ideas for this?

>

Excellent!

I figure that this works by switching the banks between the interlace, so lines  from each bank get interleaved(?). I had wondered if this was possible, but I  don't have shadow RAM to try it with (If this works well enough I might get  some!). Once selected how well does it sit with the rest of the system (ie is it transparent?), or are special drivers needed? Will it work with any shadow  board?

The obvious thing would be to develop some sort of windowing environment (the  old res realy wasn't enough for this). Once I get BCPL running I was planning to add some O-O extensions (as in Objective C) - I consider such things esential for windowing. It would then be pretty easy to get something like the  original Mac finder up and running.

Have you tried converting the GIF viewer to it? Mode 0 stuff looked pretty good  -twice the res would be excellent.

Keep text the same physical size, and but write some font drivers. Double res  would allow you to add serifs and other cute features without overly crowding  things.

Acorn failed to see the graphics revolution, and hence support for the above  stuff is limited. Therefore its probably something worth invsetigating further.

Ian


Re: A new thing...1
Date: Wed, 12 May 93 17:24:28 BST

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: Re: A new thing...

> Excellent!

> I figure that this works by switching the banks between the interlace, so

lines

> from each bank get interleaved(?). I had wondered if this was possible, but

I

> don't have shadow RAM to try it with (If this works well enough I might get

> some!). Once selected how well does it sit with the rest of the system (ie

is

> it transparent?), or are special drivers needed? Will it work with any shadow

> board?

Some bad news for you... This is master only. Beeb shadow ram boards (at leaset, the ones I've seen) are completely different in operation. The problem is that the 6845 is wired into the main RAM, and needs to be because it is that which carries out the refresh. Hence the screen is always displayed from main RAM. If you put shadow mode in, the main RAM is paged out & the shadow RAM paged in, so all your data is stored in their. Then OSWRCH is trapped & the main RAM paged in before & out again after. There is no physical way of displaying the screen from the shadow RAM.

I know this because I tried to do it, & then had to disassemble the controlling software to find out why it didn't work. Obvious really. What confused me is the manual stated clearly that the screen was displayed from shadow ram, but they are definately lying. :-(

On the bright side, masters are quite cheap now... Ask Richard Whitehand (who should be listening in to this...), he's got half a dozen & they are currently in his bad books, so he's bound to be keen to get rid of them. :-)

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


A new thing...1
Date: Thu, 13 May 1993 14:58:17 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: ian@ohm.york.ac.uk

Subject: A new thing...

>Have you tried converting the GIF viewer to it? Mode 0 stuff looked

>pretty good

I did not know a gif viewer had been written. What's the status of this?

Is it PD, is source avaliable, or is the author around? It'd be best if the original author did the conversion...

Either way, I'd like to see the viewer! :-)


Re: A new thing...2
Date: Thu, 13 May 1993 13:23:56 +1000

To: bbc-list@ohm.york.ac.uk

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

Subject: Re: A new thing...

At  2:58 PM 13/5/93 +1200, David Andrew Sainty wrote:

>I did not know a gif viewer had been written. What's the status of this? >Is it PD, is source avaliable, or is the author around? It'd be best if >the original author did the conversion...

>

>Either way, I'd like to see the viewer! :-)

Same here... never heard anything before on this one.

JR

-------------------------------------------------------------------------- Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


screens and modems and stuff
Date: Thu, 13 May 1993 14:36:07 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: screens and modems and stuff

Double vertical res:

The interlace is first forced on accessing 6845 register 8. What I've done is first switced interlace off for a frame, then on, in the hope that this will consistantly switch between primary and secondary frames on alternate Vsync interrupts. This seems to work, but I haven't tested it too much.

>From then, it is simply a matter of switching back and forth between the two screens by flipping bit 0 of ACCCON.

I haven't done anything with it apart from the initial test program to see if it worked. Martin is right, this will only work on a master as it stands. Perhaps a reduced screen height could work, eg two frames of 20 lines height for 40 lines total and 24k memory. Hmm... hardly worth it, is it!

To use it properly requires new video drivers, which I have not done. It needs to write alternate lines on alternate screen banks, quite messy!

Horizontal resolution increase I too don't think can be done. If my A User Guide is correct, there is no way to increase the video clock rate further.

You can squeeze a few extra characters on the edges tho! :-) (I think I got mode 0 up to 86 characters before it gave up).

I like your colour idea Mark! With two mode 0 screens flipped between, one red, one green, that at least gives 4 colours for the same res. I'm not sure whether this would look better with interlace on or off, off I guess?

Richard said:

>Oh yummy....let me at it! Yes, I've noticed that the existing version

>doesn't cope with most ZIP files on PC boards...but it has still been

>useful! Various folk were VERY keen on it when I told them about it - I take >it its alright if I put a copy up for download on my BBS?

Yes, treat it as fully public domain. Err, tho now I think about it, perhaps it'd be better to wait for the new version. Or, just put it up, but warn people that a new version with a number of fixes will be released very soon.

When you say it dosen't cope with most zips, I assume you mean ones using the new algorithm, not that it fails to correctly unzip imploded files?

The new version still does not handle shrunk or reduced files, but as these will now be even RARER with deflation on the rise, I have even less inclination to implement them now! :-)

>MNP2 is pretty sad tho'...although I suppose its the only level before its >'non-PD'...V42bis would be nice, although I take it it would have to be some >form of asynchronous version? Like the bodged MNP5 on some PC software?

V42bis has to sit on top of an error correcting protocol. MNP2 is the only asynchronous protocol that is common (as it is part of the V.42 definition). I don't know how MNP5 is done on PC software though, I thought that was synchronous by definition....?

People.... Should I even bother with MNP2? Or should I go straight to V.42 with additional hardware? It is true that MNP2 is not a patch on V.42, and it is ALSO true that it may not even work with V.42bis on most modems. I'm inclined to just go for the big one! :-)

>We should be launching a PD viewdata terminal of a very advanced nature soon, >no doubt Martin Ebourne will tell you all about it...MARTIN!...

>Basically, should cope with baud rates up to AT LEAST 38400, mouse controlled >windows, scrolling (continously updated) information bar, xmodem(-1k), Ymodem

Very nice indeed! Viewdata is all but forgotten in NZ unfortunately. I take it it is still a common communication form in UK?

How about making the V.42 support hardware a standard and support it both in your program and in tequilacomm?

>It really is good the amount of stuff thats now being done for the beeb in

>the comms scene...

It is indeed! Especially because it can handle it very well! It makes an excellent terminal (And with custom software, you always have the features you want! :-)

Dave.


screens and modems and stuff1
Date: Thu, 13 May 93 9:59:45 BST

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: screens and modems and stuff

> Horizontal resolution increase I too don't think can be done. If my A User

> Guide is correct, there is no way to increase the video clock rate further.

> You can squeeze a few extra characters on the edges tho! :-) (I think I got

> mode 0 up to 86 characters before it gave up).

Indeed.. Not a lot of use though...

> I like your colour idea Mark! With two mode 0 screens flipped between, one

> red, one green, that at least gives 4 colours for the same res. I'm not sure > whether this would look better with interlace on or off, off I guess?

Sounds interesting... I should imagine most of this is giving some pretty horrible flicker though...

> The new version still does not handle shrunk or reduced files, but as these

> will now be even RARER with deflation on the rise, I have even less inclination

> to implement them now! :-)

Oh, definately... Anyone with any sense uses deflate... Amazing compression ratios...

> >MNP2 is pretty sad tho'...although I suppose its the only level before its

> People.... Should I even bother with MNP2? Or should I go straight to

> V.42 with additional hardware? It is true that MNP2 is not a patch on V.42,

> and it is ALSO true that it may not even work with V.42bis on most modems.

> I'm inclined to just go for the big one! :-)

MNP2? Bin it... Go straigt for V42... Much nicer. (Even better V42bis. :-))

> >We should be launching a PD viewdata terminal of a very advanced nature soon,

> >no doubt Martin Ebourne will tell you all about it...MARTIN!...

> >Basically, should cope with baud rates up to AT LEAST 38400, mouse controlled

> >windows, scrolling (continously updated) information bar, xmodem(-1k), Ymodem

Yeah, well, erm, basically it'll be nice 'n fast & very trendy... :-)

Just like the host really. :-)

> Very nice indeed! Viewdata is all but forgotten in NZ unfortunately. I take

> it it is still a common communication form in UK?

Just so long as we're around it is. :-)

> How about making the V.42 support hardware a standard and support it both in > your program and in tequilacomm?

Urg, erm no thanks. The idea of Challenger Terminal is to go **FAST** to

keep up with decent modems... Hence V42 is already in hardware.

Also the minor problem that Acorn have just released the RO3 PRMs & I should have my set today, so at last I'll be able to program that damn A5000. Hence I'll be doing less on the Beeb. :-(

> >It really is good the amount of stuff thats now being done for the beeb in

> >the comms scene...

>

> It is indeed! Especially because it can handle it very well! It makes an

> excellent terminal (And with custom software, you always have the features you

> want! :-)

It can handle it better than my A5000. Bah!

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Re: GIF viewer
Date: Thu, 13 May 93 09:53:27 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: GIF viewer

The gif viewer was written by Andrew Leahy <A.Leahy@st.nepean.uws.edu.au>. He  mailed me a copy about 6 months ago following a mention of it on the list. It  runs on a UNIX box, and uses PBMtools to convert the gif into a simple ppm  image. It then converts the image into VDU codes which can then be transfered,  and very simply displayed (they're pretty compact too - little worse than raw  bitmap).

The version he sent me had a few problems (I don't know why as it had worked  for him), and I made quite a few mods. The main problem which I never tracked  down is that it core dumps imediatly prior to terminating! However the images  can still be used.

The original version supported modes 1 and 2. I added mode 0. I'll put what  code I've got on shiraz (assuming Andrew doesnt object), with a demo file  (gravity.vdu).

Ian


Re: GIF viewer1
Date: Fri, 14 May 1993 22:17:23 +1000 (EST)

From: Andrew Leahy <A.Leahy@st.nepean.uws.edu.au>

To: bbc-list@ohm.york.ac.uk (BBC Mailing List)

Subject: Re: GIF viewer

>The gif viewer was written by Andrew Leahy <A.Leahy@st.nepean.uws.edu.au>. He  >mailed me a copy about 6 months ago following a mention of it on the list. It  >runs on a UNIX box, and uses PBMtools to convert the gif into a simple ppm  >image. It then converts the image into VDU codes which can then be transfered,  >and very simply displayed (they're pretty compact too - little worse than raw  >bitmap).

Hey, that's me!

I ended up writing two versions of the program.

One converted the PPM files into VDU codes directly for display using a comms program that supported BBC VDU sequences (I use Termulator for this - does Tequilacomm support VDU codes?)

The other converted the PPM files to an intermediate format for d/load to the Beeb. I then had a program to display these files on the Beeb. The "intermediate" format wasn't compressed (20K Mode 1, 15K Mode 2 depending on the dimensions of the image). But it meant I could save the image to disc, display, then SVPIC it.

This "format" also allowed me to d/load (what I called) BIG images, ie. larger then what will fit on the screen, eg. 320x160+ in Mode 2. I had a display program that allowed me to scroll up and down over the image (pretty slowly...but it worked). I have about 10 or so DFS discs full of "images" (of varied content :)

>The version he sent me had a few problems (I don't know why as it had worked  >for him), and I made quite a few mods. The main problem which I never tracked  >down is that it core dumps imediatly prior to terminating! However the images  >can still be used.

Well it used to work for me, but ever since we got a new terminal server (about a year ago) for the modems I get garbage...arggh. I haven't really had the time to figure it out (specially when I've got to pay the phone bill!). It never core dumped on me.

>The original version supported modes 1 and 2. I added mode 0. I'll put what  >code I've got on shiraz (assuming Andrew doesnt object), with a demo file  >(gravity.vdu).

Don't suppose you could mail it to me!

shiraz is very temperamental from here!

(PS: I keep mentioning this but no-one seems interested. I've patched the XV program (X11 image display program) to load SVPIC'd images. Not that I use it very much...it was just an interesting exercise!) __________________________________________________________________________

Andrew "Alf" Leahy                         email: alf@st.nepean.uws.edu.au University of Western Sydney - Nepean.            A.Leahy@uws.edu.au

Sydney, Australia.                         phone: (047) 360622 (work)


GIF viewer
Date: Tue, 18 May 1993 17:23:42 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: A.Leahy@st.nepean.uws.edu.au

Subject: GIF viewer

A.Leahy@st.nepean.uws.edu.au says:

One converted the PPM files into VDU codes directly for display using a comms   program that supported BBC VDU sequences (I use Termulator for this - does   Tequilacomm support VDU codes?)

Yes, but not as well as ansi. Scrollback etc are all disabled while BBC mode is on. it's the "BBC graphics mode" option under the display menu.

(PS: I keep mentioning this but no-one seems interested. I've patched the XV program (X11 image display program) to load SVPIC'd images. Not that I use it very much...it was just an interesting exercise!)

Heh! Well, I'm interested, but I know I'd never use it! :-)


BBC: Caps lock off via software?
Date: Mon, 17 May 1993 21:49:20 +1000

From: justin@tasman.cc.utas.edu.au (Justin Ridge)

To: bbc-list@ohm.york.ac.uk

Subject: BBC: Caps lock off via software?

Hi folks, I haven't seen this done before, so I don't know if it'll be an easy or a hard question.  How does one toggle caps lock via software?  i.e. is there a status byte somewhere which one can read/write to set caps lock?

Ideas appreciated,

JR

-------------------------------------------------------------------------- Justin Ridge,                    |   Phone:  +61 02 202811

Information Technology Services  |   Fax  :  +61

 02 231772

University of Tasmania           |   Email:  Justin.Ridge@cc.utas.edu.au --------------------------------------------------------------------------


BBC: Caps lock off via software?1
Date: Mon, 17 May 93 17:29:51 BST

From: RWF Whitehand <R.W.F.Whitehand1@loughborough.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BBC: Caps lock off via software?

>

> Hi folks, I haven't seen this done before, so I don't know if it'll be an

> easy or a hard question.  How does one toggle caps lock via software?  i.e.

> is there a status byte somewhere which one can read/write to set caps lock?

>

Its in the advanced user guide, FX something or other...Martin is bound

to remember it...or I'll look it up if you don't have an Advanced User

guide...

Regards,

Richard.

------------------------------------------------------------------------------

 Challenger BBS - Fast Viewdata - v23/22/22bis/MNP2-5 - 24hrs - 021 445 3913 ------------------------------------------------------------------------------

 SysOp: Richard Whitehand - R.W.F.Whitehand1@uk.ac.loughborough

                            R_Whitehand@uk.ac.loughborough.hicom ------------------------------------------------------------------------------


BBC: Caps lock off via software?2
Date: Mon, 17 May 93 19:19:56 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: BBC: Caps lock off via software?

>From: RWF Whitehand <R.W.F.Whitehand1@lut.ac.uk>

>

>> Hi folks, I haven't seen this done before, so I don't know if it'll be an

>> easy or a hard question.  How does one toggle caps lock via software?  i.e.

>> is there a status byte somewhere which one can read/write to set caps lock?

>

>Its in the advanced user guide, FX something or other...Martin is bound

>to remember it...or I'll look it up if you don't have an Advanced User

>guide...

Don't have my AUG with me, but I think it's FX 202. I think its FX202,48 to turn CAPS LOCK off (one of the bits 32+16 controls the LED, the other controls the lock behaviour).

a.


BBC Caps lock thru S/W
Date: Tue, 18 May 93 00:36:45 +0100

From: smcgnnss@unix2.tcd.ie (Stephen McGuinness)

To: -v@unix2.tcd.ie, bbc-list@ohm.york.ac.uk

Subject: BBC Caps lock thru S/W

Hi all,

I have the AUG beside me so I hope this helps:

Name: Read/write keyboard status byte

call address: &FFF4

A=&CA (202)

For the Beeb:

bit 3 -1 if shift is pressed

bit 4 -0 if caps lock is engaged

bit 5 -0 if shift lock is engaged

bit 6 -1 if ctrl is pressed

bit 7 -1 shift enabled, if a lock key is engaged then shift reverses the lock

The old status byte is returned in X

<new value>=(<old value> AND Y)EOR X

I hope all this helps.

While I am here - a question about the Master ROM sockets

There is one free sideways ROM socket an the master and I have ViewStore in it at the moment Can I page out one of the sideways RAM banks and put this EPROM (VIEWSTORE) in the free socket ???

Does it matter that the EPROM is 16K (I think) and the socket is 32K wide??

I hope my question makes sense!

Many thanks

------------------------------------------------------------------------------

Stephen McGuinness                    |   The Usually Disclaimer.

JS Computer Engineering,              |---------------------------------------

Trinity College,                      |   This Area could contain your

Dublin, 2.                            |   Advertisment - Contact ........

Ireland.                              | ------------------------------------------------------------------------------


shift/caps lock in s/w and sideways ROMs
Date: Tue, 18 May 1993 11:25:23 +0100 (BST)

From: "Mark J E Bellis - H601/91" <u1mjeb>

To: bbc-list-request

Subject: shift/caps lock in s/w and sideways ROMs

> Name: Read/write keyboard status byte

>

> call address: &FFF4

> A=&CA (202)

>

> For the Beeb:

>

> bit 3 -1 if shift is pressed

> bit 4 -0 if caps lock is engaged

> bit 5 -0 if shift lock is engaged

> bit 6 -1 if ctrl is pressed

> bit 7 -1 shift enabled, if a lock key is engaged then shift reverses

> the lock

>

> The old status byte is returned in X

> <new value>=(<old value> AND Y)EOR X

I think there is some way of setting up the shift-caps lock state on the master - where shift gives lower case letters, but i can't remember the

mask for osbyte 202 at the moment.

-----

> While I am here - a question about the Master ROM sockets

>

> There is one free sideways ROM socket an the master and I have ViewStore

> in it at the moment

> Can I page out one of the sideways RAM banks and put this EPROM

> (VIEWSTORE) in the free  socket ???

>

> Does it matter that the EPROM is 16K (I think) and the socket is 32K wide?? >

> Stephen McGuinness

There are 3 ROM sockets in the master.

one is the 32K socket for ROM 8.

the other two are the sockets for 32K ROMs which replace the 4 banks of sideways RAM when links are changed - one for banks 4 and 5, the other

for 6 and 7.

I forgot the IC numbers off hand, and i don't have the reference manuals

on me.

If you want to put in another EPROM, you will have to lose 2 banks

of sideways RAM by placing the ROM in one of the 2 sockets and changing

the link next to the socket. The socket will take a 32K ROM, as 2 banks

of sideways RAM = 32K.

If the ROM is only 16K, you will probably end up with 2 copies of it

in the memory map, as it will not take account of the most significant

address bit. It won't matter whether you choose bank 4 or 5 (or 6 or 7),

as the image in either bank will be the same.

---------------------------------------------------------------------------- Mark Bellis

2nd year undergrad in Electronics at York University

email: u1mjeb@ohm.york.ac.uk ----------------------------------------------------------------------------


BBC Caps lock thru S/W1
Date: Tue, 18 May 1993 17:02:59 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: smcgnnss@unix2.tcd.ie

Subject: BBC Caps lock thru S/W

smcgnnss@unix2.tcd.ie says:

   Name: Read/write keyboard status byte

   call address: &FFF4

   A=&CA (202)

   For the Beeb:

   bit 3 -1 if shift is pressed

   bit 4 -0 if caps lock is engaged

   bit 5 -0 if shift lock is engaged

   bit 6 -1 if ctrl is pressed

   bit 7 -1 shift enabled, if a lock key is engaged then shift reverses the lock

   The old status byte is returned in X

   <new value>=(<old value> AND Y)EOR X

I have a feeling that this does not actually alter the led display until

a keyboard interrupt is fielded. *fx118 will update the led's.

Alternatively you could directly access the 8 bit addressable latch driven

off the system VIA, but this is messy (and can't be done safely from BASIC).

   While I am here - a question about the Master ROM sockets

   There is one free sideways ROM socket an the master and I have ViewStore in it at the moment

   Can I page out one of the sideways RAM banks and put this EPROM (VIEWSTORE) in the free

   socket ???

   Does it matter that the EPROM is 16K (I think) and the socket is 32K wide??

Unfortunately, doing this will cost you two ram banks, not just one. The

16k and 32k chips have a physically identical interface (apart from one extra

line on the 32k device that is unused on the 16k device). So the 16k chip

will behave just fine under the 32k interface. You'll probably get two copies

of Viewstore appearing though instead of one.


UnZip 1.2
Date: Wed, 19 May 1993 07:21:03 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: UnZip 1.2

UnZip 1.2 is now completed! It handles the newer "deflate" algorithm, which is becoming the most common form of zip file. It also contains a number of enhancements over UnZip 1.1, and fixes some nasty bugs.

Hopefully no-one objects to me posting this directly to the mailing list (?)

The following is a single uuencoded file. uudecode it (using the standard uudecoder), then *EXEC it on a BBC.  This will build two files, UnZip, and ReadZip. *unzip ReadZip, and you're done!

ie.

*uudecode unzipuu

*EXEC unzipx

*unzip ReadZip

Have fun!

Dave.

-------------------------- cut here ------------------------

table

 !"#$%&'()*+,-./0123456789:;<=>?

@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_

begin 644 UnZipX

M#2I"05-)0PU61%4R,0@(" @("" @(" @( L-249'150\/B9$03I0+B)"860@z M87)C:&EV92(Z3U,N(D98,3$Y(D5,4T50+B)%>'1R86-T:6YG+BXN(CI&+D$Ey M/3@Q.3)43S@T,C<Z/T$E/4=%5#I.+CI#02XX,C Y!@L-VB#%(*( O<H@(./_x MZ,D-T/5@H@ @X/^P)YT !R#N_^C)#=#PX 'PV:D-(.[_H ^I"2#N_XC0^H1Rw MH@T@X/^0!*(4T'^5>,H0\H9TAG6I)85SI8*-8""%AJ6#A7%I)86'P #P*2#@v M_[#7D7*B"$5UA74&="9UD RE=$DAA72E=4D0A77*T.O(T-?F<]#3QG$0TZ5Tu MQ7C0*J5U17G0)(6"A7BB!X9YHO^&A(:%AHB&B:(EAH.B>*@@W?^B!2 %($P1t

M(*(,( 4@J7=,]/]$;VYE#4-20R!/:PU"860@0U)##4%R8VAI=F4@97)R;W(-s

M56Y::7 -   /B   )K$  !D 0Z!HA7!HA7&@ .9PT +F<;%P2"E_(./_:!#Or

MYG#0 N9Q;'  J4"B<* P3,[_($09 +5"860@:&5A9&5R *1Y\"&I $S._R [q M&:1X(#\9J0"%](TP_B#G_Z(OO:PPE6#*$/A@(&@AJ7X@]/^*\ -,1QFB!"#Pp

M&[#3K0 PR5#0KJT!,,E+T*>N S#*[ (PT!K@ ]"X(.?_J?^59,H0^Z(:((@:o

MH@ @U_^0 TPK&<DN\ Z=<##)+] "H@#@!_ !Z,X6,-#AJ0V=<#"B +UP,,D-n

M\ 8@[O_HT/.I("#N_^C@#-#XH@"&>Z "N1(P(!$<B!#WK0(PA7JM!#"%CZT8m

M, T9,/!ZH@0@B!JB ;T ,-WN&] ORA#UK0,PT">M C"%>^CD>_ 1(-?_L G@l M#+#RG3PPD.U,*QFI . ,L"6=/##HT/:I "#?&ZT",!AE<(5PK0,P97&%<9 &k

MYG+0 N9S(-T;K1@P..T", @XZ02-&#"M&3#I "CM S"-&3!,^!FE>] ?(  9j M($YO(*#0'2#P&["B8"  &45N8W)Y<'1EY$S-&R  &2!997.@J0 @WQNB * #i M&+5P?0XPG6PPZ(@0]+J./R)&>K#+I8^B Z #W=4:\ O(RA#W3 4<" 8  82/h

MAGW@ _ 1I71**0C0"I 0(+DAL M,PQNI " <(DS-&R1T4 P@0ARP)J(&(&(=g

M\.6E= HI$$D0\$6P," B&:CP*B _&:5T*2#P""!-')#A3$<9(#(<L/BB"B!Bf M'?"WR5+PZ,E)T 4&=#AF=*F ("09A7FB ZD G6@PRA#ZJ00@'"*I3(W2':F e MC>X=C=8="H6.C84DIH\@3R.B [5D2?_="C#0:,H0]"  &4_KI'GP0R _&85Yd

MH +%>[ X2*(#O3PPG2HPO4 PG2XPO40PG38PRA#KF$BB** P(-W_:*AH&&D$c

MR, %T-#P"B  &5-K:7!P9>0@TQM,9!FB [UL,)5PRA#XJ0&D>*)P3-K_(  9b M0F'DT)B\"X9PH@"D>"#7_[ )G0 PZ.1PT/,88"  &55N:VYO=^[0O$A*2DI*a M(!P<:"D/T 3@ / ,Z DPR3J0 FD&3.[_J2#0^2  &4]V97)W<FET9;],X/\@z

M !E5;GII<+_0\JD^(.[_H@ @X/^P+9UP,,D-\!S)()#PR7_P"N >\.@@[O_Hy

MT.+@ /#>(.[_RA#8Z*E_(.[_RM#Z&&"I12#Z'*  Q&K0!J5IQ6OP)K%H162Jx

MO0 G166%9+T *$5FA66] "E%9X5FO0 JA6?(T-3F:1#0..DWT 3  / RHC<@w M&QY,AQRD:,1JT""D:<1KT!JI4$P^(B!$&0"V4VAO<G0@6FEP *  L6CPVN9Hv

M\ 1@2- -YFFD:< [T/2&=4BI!*  A&BN$##0#85IK@\PY&FP!*P.,(JF>"!!u M'JDWC9(FA6FM#C X[94FC0XPK0\P[98FC0\PL /.$#"I!"!<'K"5K9$FA6JMt MDB:%:\D[L 6I *B1:FBF=6!(J7\@?QQH*=_)3F"@ )%B162HN0 G166%9+D s M*$5FA66Y "E%9X5FN0 JA6?F8O 2SA(PT RD8J5C..D[(!D>J0!@K1,PT!"Mr M%##0"*G.C9,=[A(PSA0PSA,PI&/(P'S0#*E!H ",UAT@&1Z@.X1C3),=H@#0q MNHSK':SN'<C P- "H(",[AV] /^= (#HT/?HT)Z@ (1BH#N$8Z!@K1,PT VMp M%##0!:#.K1(PSA0PSA,PC),=J&"B.XZ2)J9Y\!X@01ZB [UH,)V9)LH0]ZD!o M(%P>H@.]F2:=:##*$/=@CI FC)4FC98FJ0"-ER:-F":-D2:-DR:-E"9@HI"@n

M)DS1_Z  F)&$H *1A*6$&&D$A820 N:%8*6$E0"EA94!8*DKA6^I (5N8* _m MA(8@>!X@[QR%?JDKA7^B_X:'(.\<Z)T *TI*2DHX98>%A^1^T.REAT6&\ 6Il M.$P^(H6/I82%@J6%A8,@@1ZHHA^%<(5QG4@PRA#ZL6XI#QAECZJQ;DI*2DK@k

M$+ ,.'U(,)U(,) #_E@PQ'[P!\C0V^9OT->E;\5_T/.B$*  A'6$<H1SA&R$j M;:DMA7;*,%3@#R9R)G.I #C]2#"%@*D _5@PA8&PYJ5PD74897*%<*5QR)%Ui M97.%<<C0 N9VYH#0Y>:!T.&8G4@PI7:=6##0O, "T HX;@$MJ2W%=O +J5=,h

M/B*E< 5QT.<@8QZ@ *DKA6^$A[%NJDI*2DJ%AHHI#QAECQ .I88X96R%;) "g MYFU,(B"JAH&]2#"%=;Q8,(B$=J  B+%U18^%<8BQ=46/A7"$?:6!A8"E@H5Rf MI8.%<P9P)G$J"BD"J*6 \"2Q<O ,JLBQ<H5RAG/&@!#CI861<JK(I821<H9Se MA7(@8QY,Y!^E;0F D7+(I6R1<N9LT +F;:1]QH80G*:!F!A]2#"=2#"P ]Y8d M,*2'Q'[P",C0 N9O3'X?I6_%?]#R8*D A82I,86%8" %'49Z9GP@-R"@ (2)c MA'*8HCN&<Y%RR-#[Z.!\T/1&>I 'HHB@_R",'J*,((H>HHH@BAZI (6"(/4=b M\!$@0"&0$Z6)\ D@%R$@;AW0[V @52%,B2"IP"1\, *IH"! (6J0^H5@I(JFa

MBR ;(4IF8)#[A6&DC*:-(!LAIHG@ :II 85RJ0"%<^ _T P@52$897*%<I "z MYG,@W2#0H6"E8ACE8(5@I6/E89 $R3NP FE!A6&@ +%@(' =\!NE<O 3QG+Fy M8-#MIF'HX'S0 J([AF'0X,9S$.E@I(BFB8:#1H[P$) "R,BQ@C 2JLBQ@JA,x M&R&$=B!%(:1V3"$A2LBQ@F!&CO !8*H@[QPX:H6.BF @12%,6R&I@$:.\/1Jw

MD/E@J9 @5R%*D/U@H "$9(1^H BB ZD E63*T/NE9$J0$J(#M61J7;4AE63*v M$/6(T.OP"T9G9F9F969DB-#>I'ZE9)D )Z5EF0 HI6:9 "FE9YD *LC0MF @u M@[AMH/^$?J( R+F.,,DCT J]<##)#? HZ-#NR2K0$8KF?J9^G0 K2)B= "UHt

MJK#9O7 P(!$BV8XPT 7)#=#98*9^,!6\ "W^ "N] "NJO6\PR0W0M,9^$.<8s

M8,EAD ;)>[ "*=]@&&5]JKQ<(J(,N6,B2"E_(.[_R,IH$/*I(,HPXR#N_TPUr

M(J( FD@@ !D-("TM($5R<F]R.J!HJ" E(B [&4S-&Q0,  8O)AQ3=&]R9>13q M:')U;NM);7!L;V1EY$1E9FQA=&7D17AT<F%C=&ENYT5X<&QO9&ENYTEN9FQAp M=&ENYT)A9"!I;G1E<FYA;"!D871A(&AE861E\D)A9"!::?!4<F5E(&EM<&QAo M=7-A8FSE0F%D(')E;W!E[J( AO2.,/ZL!X"B [D @-V,)M 1R,H0]*;TZ. 0n MD..I@(5WT$"@ +D @$G_F0" V0" "$G_F0" *-#=R-#II?2%=Q 7( 4=(/4=m M\"ZF=^C@$; 2RC"JAO2.,/ZI+(W2':F C84D($ A"*D ($ A*B! (2JJ($\Cl M*)#K8+U8(TB]7R-(8"4C(QX<(".#>66WAC\7(#<@HHB@ "!/)J**H D@3R9,k

MS2,@-R @7R&%B"!?(86*HA*I )T *\H0^JF((&$A&&D$A7ZB (:&J80@82&Fj

MAKQR)ID *^CD?M#LJ2N%?ZD2A7ZBC"!X'B 8)J*(.""U):**&""U):( AH+Hi

M\ H@%R&P"B!N'=#V8*G_T"+P^<D=L/:JRHK)") 5*0,)!(5RBDI*JKV#)B!7h M(49R:I#[&&D"A7*I "J%<Z2*IHL@&R&@ (1AR0200:HI 0D"A6"*2LD)L VJg MO8,F(%<AA6&I / >T D@52&%8:F T!-((%4AA6%HJKU[)B! (69A:I#X1F!Ff M86J0^:1AA6# 0; ?(-T@3-(CI'GP$" _&:G C84D("09A7FJT FI9TP^(JD e M$..E83CI085AI'*F<\1@BN5AD 2D8*9AA'Z&?\C0 >B*IGD@01ZE<CCE?H6&d MI7/E?X6'J2N-DB8897^%?Z5W$$&E8#CE8H5@I6'E8QAI?(5AK6@P&.5@C9DFc MK6DPY6&-FB:M:C#I (V;)JUK,.D C9PFJ0,@7!Z02$Q_) J-(R70,*5B&.5@b MJ*WN'>5A*3\)@(TC):( J2N-)B6Y /^= "OD?O 5R- *[B,EK2,ER<#PRNC0a MYNXF)=#AK28EQ7_0Y*5BA6"E8X5AH &B *6&\!W&AJ%@D7[F8- ,YF&E8<E\z

MT 2I.X5AR-#CYG_0W\:'$-^@ (1@J2L@\"!,TB.&CB#O')5PZ. #D/9)_]5My MT'+@!-#LYG+P"B#O'"!N'=#T\-GF<]#RJ5@@[O^I_]#,M0"%?B"!'BJ%?^9^x M('@>J0"%@J5_,#P%?O [I(RFC2 ;(<D0L 2@ / 8\!NB ,D1T!NIA* !2(H@w M'29H(&$AJ*5](!TFD,RF?:F"T.>@":G T.-,N!ZE;CCI 85^I6_I (5_J?],v MO1Z%?82&I7X8Y8:%?IB@ + "QG^%ALD0D *I#X6'"@H*"@5]D6[F;M "YF^Eu MAACEA[#A8""!'B!X'IBJO68F\*_HO&8F(!TFZ-#Q"(\);P<7" < !1\ $!$2t

M  @'"08*!0L$# ,- @X!#X&"A(B0H, I0R@ (  956Y::7 @5C$N,B H0RD@s M1"Y386EN='D@,3DY,XU@HB^U8)VL,,H0^*7TC4T9J0"%>:@@VO_)!/ %J0J-r MN!FI_X5WJ0&$="#A&Z( ()@GD%^M<##)+= PH@&$?KUP,,D-\!@IW\E"\%"@q

M@(2&H 39DR?P"T:&B!#V,#6D?M#+I70%AH5TZ-#4HAX@F">0'N9TH@"@ +F.p

M,,DJT 79CS#P!R 1(IV.,.C(R0W0Z$S+)R"0)B!"*$Q,&>B]<##)#I#O*=_Io

M$) .R0J0%.D'R1"0#LDW\ >I_X5W3!<G:M#XA?2-,/Z@ +D @$G_F0" V0" n

M"$G_F0" *-#?R-#II?00UE164E-)J1Z%?K%PR,D@\/60%IUP,.C&?O /L7#(m MR2&P\:D-G7 PB#A@($P9 -9.;W0@9F]U;F0 J8,@]/_ %+ :H!.,/""I,8W l M'(W('(TF':D*C0D=J4N-B!RIA"#T_\!\L 4@ !D6AR"0)B B&8XH,(PI,*CPk

ML85X(  9#49I;&5N86UE(" @($QE;F=T:"!"0D,@365T:&]D(" @(" @0U)#j MC:(FJ3T@?QQ,81D@ !D-57-A9V4Z("I5;EII<" H+5M2(%,@22!4(%8@0CQ2i M86T@8F%N:SY=*2 \6FEP(&9I;&4^("@\9FEL92!S<&5C/JE@4F5A9%II< T h

M  Z-_____P    "V%E!+ P0*  8 !@#Q-K,:I$!I\Q\.  !C(   !@   %)Eg M861-96$*>P<&&P:[#$L#"0<+"0L)!Q8'" 8%!@<&!38'%A<+"@8("@L%!A4$f M!A<%"@@%!A4&"B4&" <8"@<*" L'"P0E!"4$"@8$!10%"30'!A<)&BO\_/S[e M^_L,"RP++ L\"RPKK P!(B,4%38W:(F:VSP%!A(C%.7VEO?_"SQI:0)'_,0Cd M1*[2#^/>UFL__B0OQ^C0145Z5X'#"T<%?_A$N.J__5S'$NY/HD?/+BJ:3@6.c M&A05=>[S?M:['LWVQ\R,R?LF'B$5V]?ZG[]6GNV.-_B_M.W5[2GG_93[/G]Mb MN^^_[+]^K<MV->?E_M>2_R'^+WD^10GW7?I+1?'7]\9<OH_E60"Z\==2L7J>a MHVYU%?K_V)=?WNM7+1S:USX778?3#_?CGW"_>==VARU^OHYJWD\"O*_#YI=_z M^?Y[#>QISM7UA]OG7[N.NN)[+>O?2_>&,!?>:^EN7,]YAOM7#>H,OB[(OY[_y MKW+IW.MW'?2MW[7S6>YZ4>TZU7?E63Y1N_9<Y\K0G3F>QKYM=V,YPX6R(*^Hx MZ"WK?)P?K:AHJ%<.AHV]7,J+,,?G/8V\(Z3J1?:MJ*AU;]N^!L/V50?OPZUYw M\;?.SJO>!]5#7JC":"^7];MFW6>)]F,111=.(W5^^P]^ZX?Q4T.B\Y3#"K7@v MAP3-"[^&]0M# J!#UPVKH*A(YD2Y5JL^6Z-R1;@]._'76J%I+BKJEN"[*T8_u M[9C/<3KW\93O.'_Z(U?NXXYP;_Z]\,/Y:_LLM.%JU^/TG>?<[J<>[M_A)?+5t ML%FUILD;^?C7\P3+&;/EDEQ-O>+^XXX'?MQ?H7HZD)@.JH=Z+;%*W(09J,MOs MG,]:N5>Q^+SL8/W5<,OL8#M^N^3C4N_J^;8]KVW3<&,1VZ1O"OV_GT:%Z4'\r M:\*/K]RL>W-J:*:XX]MRO+;N=2%\'=[/\QS+737_P/%POU&Y&PD*8:+.J#.Bq MBH4^,[YA,%[#N.YXQM?AQ7I""E<J%@?]QX*WB)?Q-D#4[Q_^S>=(H'MM[M5Up ML2ZO3,?G]:G:A\A\D6*VH&!U=3?;%3MOQKNLZ<>CKMSAZPS^Y>?$/O_MKMW;o M?30<3PMSIRD%^835QNWD+7_(PEY!WA_>M6<^9;VMJX#U;MQ5/)_WLI#WHGGIn M?!I8"_B4M4H[B8/ZD'A?"X"3",]Y/4W.KN-E .RM-6KTC[U\'3Q>]=V0>+:+m M6_^%K6K[K3?8]TL[GL%OP'?6=\[[+=.>\@3W72O[?-9IG!#^QJSK?2QB;@_%l ML]WG7GYC0XIKON>5<+MY%Q45#?""-E?.KHSCW^%Z!Q3.''[S@9ZZ6QO1S^X3k MP19Q1VKV,OD^?LAFXRWY\WYH5A^V6MKN=?UQ0HMC'A+.+31.#^,^=HO?L7B*j M-ML0JTJ< <]]V8>8V@N^KK$P[UVK40:[;_[$S7PIDAQ]"%?EGMY_G=&WS3X6i M'-\@'BM.U.-0?]VU3XMDUOU@_C0S\[T?-V<0H"K-S>HI6#=.6'$D35-UO4J7h M<"7<6+IL7=%C>+]XL2H/H'^1GA_"M_S4>2^6LT9XO67\\4X_O$,4FI]?>C8,g M]_E\-H^RHB=Y19&OL]YXMOKZ8^DLP>03ZEWG4FG?>',=L^$?8?,;Q*YCEL#2f M:5O?_@X9D-7?BJ6<[.FR3N_D&KDKVR:R$7'XKG$DC7E6QEI<#XR'4_@:IQ4Ge M[T?&N:[Z$\'ZJADG5;:=[^$K7Y%\SK-JSQ!EY8OU75"'=U!'1[$ZK*,\-^4 d M[OEQ1NJUQ4WA4[_LNI=OO/!V6UZT+9:UA#8(\)C3!,L5NN3)NN\+O*GL$<=Jc M!>EL'LXH04D-T;G17-K=/-P"]I>A]WE'> XFY^F@DX_3$<I:&$-TN0,TMFW5b MCWEFDK\+A!N#:H5M@%/IJ0N*,BQYAM21>DUW?H-0M9H7LI6:Q3(8HQ&5P3ACa M9*9BUWQ79^ZJM(61V*4\9R'%'O==QT[8(+7GT4")7_,=Q]ZOFEF%#L:KJJF[z MA:NHNFKZ41$EGT_X$7NAL (VW-13VDE9KM]!O!$\)M3**%KSC=.&%^,:CS.@y M%U76=5&<(?25JWZ/QA8.5(E9=JUL,Y,YR:B^^%X]KA5EQ3 J9];[7%1(N%GEx ML%L)1^(ZX2J5[KJ>_EBG%]/SE81%L>,;5YM8O?/A>UKD_^#=UF934T><HK#/w MY&U&OE+;P7@C4(5@2#FD>T9O8D'Q3E7]*Y>@\G8O8H(QC?>'^K[#WPUD7I]Zv MG6:%J<'TF<3>SS)O8F)0JPT"_O5'VRBZ*Q])&-PG#V:)H_V]S:_[Y!59/^9Du MKP6MQN,9O2'498SV]CC6L6@>O*CR@/LF'(; -3#/)H&5AK&]S?NF'Q'8$618t MQ%_O>>Y*DBFXA8B%TT9_GH6:H\I./P^O#B]1]Q,U.%OC"-<^K\:7U?(USQ11s M:>7)DA8SII8?4C&N:FI^;.M-L+]4Q27$*Y?)YVJER.B8AYS%2L$L7S]+GE_=r M]SKZ?U;QK;VW6T.RN??V][->I-&"_Z5-0Y;B_>JV[Q'"(?+#HDWZC]_ 9V?Yq M>+Q<:R@EXBGBMJX0404L624?<X_HVS;;BV*XH2X'9&>P"GZVIP%DO$(86J0Yp M%7M5W(1;E[O,N0Y3VH)*)KEJQPY^D9H=F5>4,NLH7?82TRVL43[?90UW"_'Ao MY<CJOFG*/TM%RF'*4:U?I'4QWT*>1I,XTSCA[IX8-65?MOJ:GS)VWQ+R":TWn M5#.'.#-ZN94Z;B75*#:O*,H>3]K--RBMWMYJ-Q)V*"K-<$Y\UEV;#Z4R[I<1m MJ7:UR)8_I2>,L2Q^L2W2(%I WN:L;K[A.8=4DO\D1EY.9D*!KZ],H6N1#[\Jl MH?4]_N"A28-9+/#&4.>1_F_X$I91\A/$M&IT6*HWY+L\"?>/R"MO97>SY1\Nk MHE)_5'G]/+PW@_>VX)7]A*5TVL3VLP'&3Q)W#RT# _]C<9\L/#T4;^V.85"[j M#J8U><W>)6)V/N[PI8?>KX _C/5!&1IMRJD_8*"Z\D1@M) &)1)Z6/P"5'"<i M%S;U/$%+9)AXT=IXJ/WQ#-CZ"\VS:\.T!ZF@J"W@$QI5I/*\4(7NZOLI4A2Zh MTTT6H2S-*24EO]#LV5WSS41TZ9RK54(C-APJMFAXQ2+E6HKF$CC/3N&9G-V]g MC'HMSZMPIZZP%PTS&OUA+RA+* *;%;UL,+&+208SV8S%SD%TW-X;)6=))28Tf

MH_2&+ 5M:PG*V3]%%*34KH;:W 0@.DZJL<PUJ-7D;;A15-1?/!]+] =/&U1He M$?_5D3.7SZX<P9"$F-S5Q\@MK!GI%:53N%R2?Q56HUBJ"!*^:C[;EAEX2T&Ld ML(\N=Z-R7 J" 6PQ:_Z%/()1*0+?/O49U11&4F LXE0LI>U!8Y4I :+I<_"Sc M%)-9-+5WXU&(OKEMD4XNHM8C?WZTO/#Z2+IHD'\U+NLO6G'*^/7V3!?)Z;SNb M-5E[%,(0^JF/FE5 _$<<*H:EV&FH6:] 2>3;QM_%:I$G4\TG-!X5;#:I^FB3a

MU /X8.N5A\4R.LO4BIK*/4[.)IX-C1((]1#G2]%Q<[ [:Q@I'!C(VY@1-S])z M!;G+B+V&]X)%#P;&WK)-;]_:OU0;=_C;FB+G>>$)6T92]W,GSK"=+VBY\8CNy M.[&_K!W?1U+YO"&P+1JYNE?1?O->XO6UVLB>Y$V(*N[: #TQFW6NTS_^DE90x MT('UI@@1CK[KT,WNNO3>,-Z.LAM*1LV$ H*AFK;]5:9=%9A>U(S"$RJ.U^>Gw M=L:\;K:Y8?YPQ%3\ZY6V3[!_['UM\&_9ZR7'H<_!=VCB#%[?O)DKL&+U':5Vv MZ1\E=]N*9V%+=P/CZV8O^:DR[MP"33#OQN.^9AQ[M)TV2-6*0XERU5#>=(1Gu MNUS]@GH%F!+%4EP!TK 339HJ,TF\HL62O'+LV';6PGF\.BW ST.QW'4<47"[t M"#WBN2:MOI!&E;-<>%&ZQTD\W)&)4R"HT:D(T=C*H@9NB6>]6%H^+7J9_*Z.s

MU4. 5'4)X;7*Z,C;ZXY']%I[EN>4W 3"*+/(NC!=@+CA\$K";7/?]!R6D<DMr M?-P@$CV;(3B"W'7']CIF%M4ZCZ:R.'\E1A6QYKH@Q=DPX6@;7MPP@FH%QSD"q MT7?U:YEJ/2SOMZ_R16M/,N:+ZM1L(&BY#,(W.-<(J^F+JR3<%S(=CG5XG+PXp M%A9N3S;/I%#G-;;]0'G9);:/TQJ)9\0+L\S$"Q]B#,'A5FM3$-@(=+[DXVMBo M1:4UNXL:/FT6ME'Q!D'B_HQ -I+?I)*MS):J^*QGBYF>DGLI;E$+G@D\_7L3n MM,/U:P_CW\P)Z@)7*-LKC##.KSK!,C3<]J4W$'I^ZS>Z-4A].+>11#O:R^X-m

MQ5X9W? +LU-X?JU-I7RG/Y7*4-"4NF\5S-$5(7TA!1;QV95(_0R!^Y<+3DGZl M$H9844-+=-QNT-B]^-?E5.&SA/%,YDL^N*:"QS57%9L;=+&&^I 2$UX$<TBOk M6H%B^DB>.(EE?F+MC9C4MLE7C8%(VU$B)__"I''4M\ *F=V=:T3GD$^R<W,Mj MN6W>TH*RN GY2_**WV702H%.4V&7<7DBB5#8[L5$W04LX /_5*G]\8LP5,NWi MF;"(*!_@O \;_M1Q$ZY=OX*[G_7Z46+\7BW;3K$DH[ZQF.Q78"OA,$1E;]/*h MV1@FG&;E>-:S5&.TL.5916'.A:UZC+:>279>)@M*5UP:53TFE\A))M@A5VN8g M3Y7JP\=0E;]#=2]6]GZG)7[S\#:"%UU!0S8_]6TNG6Y&QN:L?^W<2R6:\$;Hf MOQ)K*3(%A D<@-6HQB,+,Z)M!T")8P[,:$ J $CBT*F)@^>Q;VB1/A!&Y159e

M, ?_/.8M!&Q[QZQPW:-]!& 0 U!+ 0(*#PH !@ & /$VLQJD0&GS'PX  &,@d

M   &            (         !296%D36502P4&      $  0 T    0PX c

$    #0  b

 a

end


Mouse drivers?
Date: Fri, 21 May 93 09:58:45 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Mouse drivers?

Has anyone got any mouse driver software source?

I decided a couple of days ago to write an interupt driven mouse system (so the  mouse keeps moving on the host, while you just run programs on the  co-processor). It intercepts the screen flyback to update the pointer position,  and intercepts oswrch to hide the pointer prior to any drawing (I then plan to  add copy and paste functions, a little like the copy key, but faster).

The problem is that I'm currently using the AMX software, which in V.1 only has  a command line interface (*hidepointer etc). This is fine most of the time, but  a little impractical during an interupt routine! (it actually works, but the  time delay gradually catches up, and crashes the system after a few seconds).  AMX V.2 does have some entry points (loads in fact - you need a co-processor to  load in the suppplied header file!), but I'm not sure thats what I want to use.

Does anyone have a couple of short routines to put a pointer on the screen, and  then remove it, restoring the previous contents? Poking the screen is fine (the  code will always be on the host), and it only needs to handle mode 0. I guess  this is pretty simple, but I never got into sprite handling.

Ian


OSWORD list?
Date: Fri, 21 May 93 13:16:10 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: OSWORD list?

I'd like to compile a list of OSWORD calls used by different versions of the MOS, Filing systems, Utility ROMs, etc., so that I can try to avoid clashing with existing programs when writing my own ROMs. If anyone has such a list, I'd like a copy, otherwise I'll start a collection. If you have any ROMs which have OSWORD calls, I'd like a summary which says what the calls do, what the input parameters are, and what the exit conditions are. I'll make the list available for FTP somewhere.

a.


OSWORD calls
Date: Fri, 21 May 1993 18:48:02 +0100 (BST)

From: "Mark J E Bellis - H601/91" <u1mjeb>

To: bbc-list-request

Subject: OSWORD calls

re: osword call requests...

i'll start you off with a few defaults:

Acorn MOS (Master 128) 	0-15

Acorn 1770 DFS	125-127

Acorn ADFS	112-116

yeah, keep me updated with the list...

mark

------------------------------------------------------------------------------ Mark Bellis

2nd year Undergrad in Electronic Engineering @ York University

email: u1mjeb@ohm.york.ac.uk ------------------------------------------------------------------------------


new FTP archive
Date: Thu, 27 May 93 14:27:39 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: new FTP archive

I've put a few bits of BBC software up for FTP on ftp.dcs.ed.ac.uk, (129.215.160.5, 129.215.186.1) in the directory pub/ajcd/BBC. They're mostly in compressed tar archives (which shouldn't be too much of a problem, because there are (largish) PostScript documents included in the archives which will need printing).

a.

--

Angus Duggan, Department of Computer Science,	| Jobless, Phdless, clueless University of Edinburgh, The King's Buildings,  | PHONE: +44(0)31 650 5126 Mayfield Road, Edinburgh EH9 3JZ, Scotland.	| INET: ajcd@dcs.ed.ac.uk


m/c optimisations
Date: Wed, 9 Jun 93 17:25:31 +0100

From: Mik Davis <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: m/c optimisations

  OK, This may seem a silly question. Anyway, here goes...

  I have a piece of machine code, written using the BASIC assembler which JUST fits in the memory available to it. I would like to make it smaller if I can. I have made all the size optimisations I can think of. I was wondering if anyone out there knows of any tips which would help me to reduce the size of my program in memory.

  I am not interested in speed of execution here - only in memory used.

  Mik

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk ------------------------------------------------------------------------------- A total abstainer is one who abstains from everything but abstention,

and especially from inactivity in the affairs of others.

-- Ambrose Bierce


Re: m/c optimisations
Date: Wed, 09 Jun 93 18:50:45 +0200

From: stjohn@poly.polytechnique.fr

To: bbc-list@ohm.york.ac.uk

Subject: Re: m/c optimisations

There is a radically different technique where you implement a byte code interpreter in machine code, then use the interpreter to run your program. Loses time, but often saves LOTS of space, especially on old fashioned architectures.

Depends what sort of program it is I suppose...

(btw. I've never understood why Small-C doesn't do this, as it works particularly well for compilers)

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93 (____/ (_/ (_/_).    ___ "You labelled me; I'll label you: ---------------           so I dub thee unforgiven" -- Metallica


Re: m/c optimisations1
Date: Thu, 10 Jun 93 10:40:38 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: m/c optimisations

>There is a radically different technique where you implement a

>byte code interpreter in machine code, then use the interpreter

>to run your program. Loses time, but often saves LOTS of space,

>especially on old fashioned architectures.

I though about this a while ago, and I'm not conviced that on a processor like  the 6502 the performace will be that much worse than real machine code  (at  least for compiler generated stuff, with little optimisation)!

Consider the code that Small C can produce - absolutly everything has to be a  subroutine right down to add and subtract, hence the code becomes

JSR push

JSR push

JSR add

JSR store

etc..

particularly as the 6502 stack is inadaquate for this sort of stuff.

With byte codes we can write

push;push;add;store;

where each is only a single byte - a three fold improvement in memory usage

(OK I've neglected operands, but the idea holds).

Performance isn't so bad as we can write the interpretter as

.loop

LDX pc

INC pc

JSR (table,x) \I think this is a bad instruction!

JMP loop

OK in practise its much worse than this, but can still be pretty efficient,  after all most of the work is done by the instruction subroutines, and these  are still the same for both methods.

Just some thoughts

Ian


m/c optimisations1
Date: Thu, 10 Jun 93 13:34:08 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: m/c optimisations

>From: I Stephenson <ian@ohm.york.ac.uk>

>Performance isn't so bad as we can write the interpretter as

>.loop

>LDX pc

>INC pc

>JSR (table,x) \I think this is a bad instruction!

>JMP loop

JSR (table,X) is indeed a non-existant instruction. On the 65C02 there is a JMP (abs,X) instruction, so you could write

        ...

        JSR dispatch

        ...

.dispatch       JMP (table,X)

On the 6502, you have to do something like:

.dispatch LDA low,X

        STA addr

        LDA high,X

        STA addr

        JMP (addr)

a.


m/c optimisations2
Date: Fri, 11 Jun 1993 08:36:13 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: ajcd@dcs.edinburgh.ac.uk

Subject: m/c optimisations

   From: ajcd@dcs.edinburgh.ac.uk

   Date: Thu, 10 Jun 93 13:34:08 BST

   JSR (table,X) is indeed a non-existant instruction. On the 65C02 there is a

   JMP (abs,X) instruction, so you could write

   ...

   JSR dispatch

   ...

   .dispatch       JMP (table,X)

   On the 6502, you have to do something like:

   .dispatch LDA low,X

   STA addr

   LDA high,X

   STA addr

   JMP (addr)

Or directly modify a JMP abs, which saves you 2 bytes of vector and is

faster anyway. Slower, but more compact, is:

LDA low,X:PHA

LDA high,X:PHA

RTS

where the low high address is the actual address -1.


Small-C optimisation?
Date: Thu, 10 Jun 93 18:34:31 +0200

From: stjohn@poly.polytechnique.fr

To: "I Stephenson" <ian@ohm.york.ac.uk>

Subject: Small-C optimisation?

>Consider the code that Small C can produce - absolutly everything has to be a  >subroutine right down to add and subtract, hence the code becomes

>

>JSR push

>JSR push

>JSR add

>JSR store

>etc..

>

>particularly as the 6502 stack is inadaquate for this sort of stuff.

>

>With byte codes we can write

>push;push;add;store;

>where each is only a single byte - a three fold improvement in

>memory usage (OK I've neglected operands, but the idea holds).

Okay, well how many codes do we need? I would have thought that operands would do even better from a bytecode interpreter.

>From every example I could think of, the bytecode version was smaller than the threaded version:

16 bit loads only take 3 bytes instead of 4(?) LDX n;LDY n

16 bit branches only take 3 bytes instead of 5(?) Bcc L0;JMP nn;.L0

....

And who's got the spare couple of weeks to do it?

But then you could just go the whole hog and implement a Z80 emulator

:) :) :) :) :) tee hee

Chris.

PS: there is no real limitation on just 16 bit words either... and the helpful abstraction of an interpreted system would allow for an interpreted MMU and paging to/from disk. The thought of running GCC in 32kb plus 2x720kb drives does make me smile though.

32016 emulator? one to avoid I think ;-)

I digress.


m/c optimisations3
Date: Thu, 10 Jun 1993 16:19:08 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: davism@uhura.aston.ac.uk

Subject: m/c optimisations

     OK, This may seem a silly question. Anyway, here goes...

     I have a piece of machine code, written using the BASIC assembler which JUST

   fits in the memory available to it. I would like to make it smaller if I can. I

   have made all the size optimisations I can think of. I was wondering if anyone

   out there knows of any tips which would help me to reduce the size of my

   program in memory.

     I am not interested in speed of execution here - only in memory used.

Well, LSR flag, and SEC, ROR flag are pretty compact flag set/clears.

And of course use branches instead of JMPs. But you probably know all

this....

How big a program is it? You could always send it out on the group and

see what people can come up with (It's a little tricky to come up with

"general rules" for size optimisation....

Dave.


m/c optimisations4
Date: Thu, 10 Jun 93 09:36:01 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: m/c optimisations

>From: Mik Davis <davism@uhura.aston.ac.uk>

>

> I have a piece of machine code, written using the BASIC assembler which JUST

>fits in the memory available to it. I would like to make it smaller if I can. I

>have made all the size optimisations I can think of. I was wondering if anyone

>out there knows of any tips which would help me to reduce the size of my

>program in memory.

> I am not interested in speed of execution here - only in memory used.

My favourite optimisation techniques include;

1) Examine the pre-and post-conditions for each block or the program carefully; you can often get away with branches instead of jumps by branching on some known flag state. You can also avoid setting or clearing flags (esp. carry) often. (For example, if you add two numbers which you know won't cause a carry set, like an address and data size, you don't need to clear the carry before another add, and you can BCC immediately after the code also.)

2) You can use BIT zero-page and BIT absolute (&24 and &2C) as skip 1 or 2 bytes opcodes, if you don't care about the flag state afterwards. This is useful for a fall-through in case-like statements; e.g.

.one    LDA #1          \ entry point

        EQUB &2C        \ skip next operation

.two    LDA #2          \ entry point

        EQUB &2C        \ skip next operation

.four   LDA #4          \ entry point

        EQUB &2C

.eight  LDA #8          \ entry point

        AND mask        \ use A as a mask

        ...

This saves on 1 byte for a branch after each LDA.

3) Use negative zero-page X indexing. If you use zero-page,X indexing, the 6502 doesn't carry the address over to page one if X+zp_address is greater than &FF. You can use this for multi-byte operations (e.g. add or subtract) where you can't perform a CPX or CPY in between (which resets the carry state). e.g., to add two numbers in zero page together:

        LDX #&FC        \ -4

        CLC

.add    LDA one+4,X

        ADC two+4,X

        STA three+4,X

        INX

        BNE add

4) Use the carry set and clear for adding/subtracting an extra one. For example, to print a hexadecimal digit, you can do:

print_nibble    AND #&F         \ print nibble

                CMP #10

                BCC print_digit

                ADC #ASC"A"-ASC"0"-11 \ C is set: A+1+'A'-'0'-1 == A+'A'-'0'

print_digit     ADC #ASC"0"     \ C is always clear here

                JMP oswrch

5) Use EOR for comparisons. This has the advantage that it doesn't affect the carry, and you can recover the data by EORing again.

a.

--

Angus Duggan, Department of Computer Science,	| Jobless, Phdless, clueless

University of Edinburgh, The King's Buildings,  | PHONE: +44(0)31 650 5126

Mayfield Road, Edinburgh EH9 3JZ, Scotland.	| INET: ajcd@dcs.ed.ac.uk


hdfs
Date: Wed, 2 Jun 93 14:56:10 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: hdfs

I downloaded HDFS a few days ago (its now on shiraz), and tried it out - its a  great piece of software!

In addition to the heirachical directory structure (not perfect but still  pretty cool), the big plus points are:

Treating both sides of the disc as continuous (400k in one chunk is much more usefull than 2x200)

RWX file attributes (including an option to autmatically exec text files - more limited than I'd like but well integrated).

The ability to change the special characters ie: you can use / to seperate directory names - why - cause then you can use .'s in filenames eg:  test.c (yey!).

Loads of extra utilities that were previously in other roms like (say) Disc Doctor.

I like this program, and may go over to using it for developing software. If  you've still got an 8271 controller thn a sugguest you check it out.

Ian

P.S. Richard York mailed me recently about building a real time clock (He's  planning a production run) - anyone interested should contact him  <yorkr@computer-science.manchester.ac.uk>.


Re: hdfs
Date: Thu, 3 Jun 93 13:29:38 +0100

From: Mik Davis <davism@uhura.aston.ac.uk>

To: bbc-list-request@ohm.york.ac.uk

Subject: Re: hdfs

>I downloaded HDFS a few days ago (its now on shiraz), and tried it out - its a

>great piece of software!

  Is this "HADFS"?

>In addition to the heirachical directory structure (not perfect but still

>pretty cool), the big plus points are:

>

>	Treating both sides of the disc as continuous (400k in one chunk is

>much more usefull than 2x200)

>

>	RWX file attributes (including an option to autmatically exec text

>files - more limited than I'd like but well integrated).

>	The ability to change the special characters ie: you can use / to

>seperate directory names - why - cause then you can use .'s in filenames eg:

>test.c (yey!).

>I like this program, and may go over to using it for developing software. If

>you've still got an 8271 controller thn a sugguest you check it out.

  If it is the HADFS which I have then it (at east my copy) acks random access fies (no OSGBPB aowed)

Mik (sorry, "l" key is broken)

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk ------------------------------------------------------------------------------- Blessed are they who Go Around in Circles, for they Shall be Known

as Wheels.


hdfs1
Date: Fri, 4 Jun 93 09:40:26 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: hdfs

>From: I Stephenson <ian@ohm.york.ac.uk>

>

>In addition to the heirachical directory structure (not perfect but still

>pretty cool), the big plus points are:

Yes, the hierarchical structure was dictated by wanting it to be Acorn-compatible, which either required two different systems for reading and writing catalogues, or to stick closely to the acorn directory structure. The latter option won in the end. Another important consideration was that there is no way of detecting when a disc is removed, so no vital information is kept in memory when the disc is not being accessed. There are time and flexibility overheads in doing it this way, but I'm quite pleased with the overall result. Another point in the current directory structure's favour is that you can copy directories around using the normal Acorn DFS, and they will still work if you use the HDFS. (Each directory is completely self-contained, with no parent or back pointers; the only piece of information particular to a directory in the parent catalogue is the D bit.)

>       Loads of extra utilities that were previously in other roms like (say)

>Disc Doctor

Which are all tube and sideways-ROM transparent, which is a major win for me (I run with a tube most of the time). Being able to auto-boot without the Tube (CTRL-I-BREAK) is another advantage, because I don't have to turn the tube off (putting nasty transients on the power lines) to play games.

There aren't any major bugs in it (I've been using this filing system exculsively for the last 4-5 years and have probably had all the nasties happen to me).

There are a couple of buglets which I've found recently (*fedit and *dump on zero-length files give the error message "Bad Start", which is not particularily helpful), but I don't really feel they're worth fixing yet.

The biggest point that I'm not pleased about is that the ROM is non-reentrant, so text printed by the ROM itself cannot be *SPOOLed. To do this, the memory areas used by OSGBPB, OSBGET and OSBPUT need to be completely seperate from the areas used by the rest of the ROM, and this just wasn't possible with the memory available. The manual contains all of the command descriptions anyway, and the syntax is available as a reminder via *help.

I've an ongoing project which I've currently shelved in favour of re-writing my assembler and disassembler ROM, to make the AMPLE ROM tube-compatible. I've got a disassembly of it, and I think that it might be possible using events driven by the interrupts from the 1Mhz bus, but I probably need more information about the hardware. Has anyone got any technical specs of the Music 5000 hardware which they can share?

a.

--

Angus Duggan, Department of Computer Science,	| Jobless, Phdless, clueless

University of Edinburgh, The King's Buildings,  | PHONE: +44(0)31 650 5126

Mayfield Road, Edinburgh EH9 3JZ, Scotland.	| INET: ajcd@dcs.ed.ac.uk


Optimisations.
Date: Thu, 10 Jun 93 14:54:58 +0100

From: Mik Davis <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Optimisations.

  There seems to be a lot of people out there who know far more about machine code programming than I do. (not difficult actually). Thanks for all the suggestions. I'll print them all out and try and translate some of them into English tonight :-)

  My exams are over now so this project is back on line.

  I would post the source code here so that people could have a look at it but there is no way to get the file from my beeb to the net unfortunatly.

  Thanks again, all suggestions gratefully received

  Mik

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk -------------------------------------------------------------------------------

A dozen, a gross, and a score,

Plus three times the square root of four,

Divided by seven,

Plus five time eleven,

Equals nine squared plus zero, no more.


Other Beebs
Date: Mon, 14 Jun 93 9:54:40 BST

From: Jeremy Prior <jez@praxis.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Other Beebs

All,

    Could anyone explain the major differences between the various BBC models - BBC B, BBC B+ and BBC Master machines.  I am familiar with (and own) several Model B's but don't know anything about the rest.

jez

--

Jeremy Prior (jez)                               Telephone:   +44 225 444700 Praxis Systems plc, 20 Manvers Street,                 Fax:   +44 225 465205 Bath, AVON, BA1 1PX, UK                              Email: jez@praxis.co.uk


Other Beebs1
Date: Tue, 15 Jun 1993 10:13:00 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: jez@praxis.co.uk

Subject: Other Beebs

   From: Jeremy Prior <jez@praxis.co.uk>

   Date: Mon, 14 Jun 93 9:54:40 BST

   All,

       Could anyone explain the major differences between the various BBC

   models - BBC B, BBC B+ and BBC Master machines.  I am familiar with (and

   own) several Model B's but don't know anything about the rest.

The main differences were the disc drive interfaces and the memory management.

Both the B+ and Master had disc drive interface as standard and used a double density capable device.

The B+ had shadow ram, and a 12k block of sideways ram.

The master has far more memory, 128k ram. That's 32k + 20k shadow ram + 64k sideways ram + 4k in sideways ram area + 8k rom workspace.

My personal favourite enhancement is the 8k ram for rom workspace. I actually designed and built something for the model B to do precisely that job, I was going to use it with ADFS and my newly aquired Hard drive, but then I got a master, so the project was prematurely halted.... Pity really! If anyone wants to carry the job on I can probably find some of my old notes, or just explain what I did...

The other enhancement between the B+ and Master is that both shadow and main memory ram banks can be displayed, or stored in main memory. The output of the OS VDU drivers can be redirected to either too, the theory being that you can do nice switching between teh banks for animation purposes. But not much has been done with that....

Processor runs the same speed. Graphics the same (I always thought they should have bunged in some minor shades capability in the Master).

Facility for internal co-processor (And internal modem, I've never heard of one though!). What else... Oh, a CMOS 6502, that's quite a big improvement! People have praised Acorn for not using a Rockwell 6502 in the master on grounds of rarety (Rockwell is slightly enhanced again). That's a pity, could have squeezed a bit more power out there....

Memory is dynamic. Oh, almost forgot! Real time clock and battery backed setup! Cartridge ports... don't like them so much, I'd prefer internal rom sockets. Numeric keypad....

Hmmm, there's more differences than I thought! OS is much improved, and has neat extras like *EDIT (which is definately where it's at! Except pity it can't edit large files off disc....).


Re: Other Beebs
Date: Tue, 15 Jun 93 08:59:28 BST

From: David Alan Gilbert <gilbertd@computer-science.manchester.ac.uk> To: bbc-list@ohm.york.ac.uk

Subject: Re: Other Beebs

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

The main differences were the disc drive interfaces and the memory 	management.

Both the B+ and Master had disc drive interface as standard and used

a double density capable device.

No - we came accross a B+ without disc interface - the cute thing on the B+ was the way the PCB was kind of partially designed for both the 8271 and 177x

The B+ had shadow ram, and a 12k block of sideways ram.

Some of the B+'s did have 128K - i.e. the extra 4 banks of sideways RAM - the B+128K

Facility for internal co-processor (And internal modem, I've never heard 	of one though!). What else... Oh, a CMOS 6502, that's quite a big

I think Beebug did a modem - what really killed it though is that most masters have a battery pack for the CMOS RAM (to replace the ones which used to catch fire occasionally.....)

Hmmm, there's more differences than I thought! OS is much improved, and 	has neat extras like *EDIT (which is definately where it's at! Except 	pity it can't edit large files off disc....).

Thats a bit of an understatement - Edit/Terminal/View/ViewStore.

Dave


searching for BBC envelope experiment program
Date: Tue, 15 Jun 1993 10:35:33 +0100 (BST)

From: "John K Nicoll" <jkn>

To: bbc-list

Subject: searching for BBC envelope experiment program

Hello all

A few ;-) years ago I had a copy of a program for the BBC B which allowed you to graphically manipulate a representation of the ENVELOPE command on the screen (the A, D, S, R type thing) and experiment with the sound it produced. I guess that it was written in BBC BASIC & came from a mag or similar. I'm looking for a copy of that program now - has anyone any leads?

thanks

john Nicoll


Fast routine required
Date: Wed, 16 Jun 93 14:24:23 +0100

From: Mik Davis <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Fast routine required

  I need a *fast* routine to move 1024 bytes of RAM across the memoru of my machine. Must be compatible with all the 6502 based machine (B, B+, master etc)

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk ------------------------------------------------------------------------------- "The warning message we sent the Russians was a calculated ambiguity

that would be clearly understood."

-- Alexander Haig


Fast routine required1
Date: Thu, 17 Jun 1993 08:28:51 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: davism@uhura.aston.ac.uk

Subject: Fast routine required

   From: Mik Davis <davism@uhura.aston.ac.uk>

   Date: Wed, 16 Jun 93 14:24:23 +0100

     I need a *fast* routine to move 1024 bytes of RAM across the memoru of my

   machine. Must be compatible with all the 6502 based machine (B, B+, master etc)

Fastest method is using an index on self modifying absolute address

instructions. eg.

lda#start DIV256:sta adr+2

lda#end DIV256:sta adr2+2

ldy#3:ldx#0

.adr lda &FF00,X

.adr2 sta &FF00,X

inx:bne adr

inc adr+2

inc adr2+2

dey:bpl adr

This works fine if the blocks you want to move are on page boundaries. If they are not, it still works but you have to program both bytes of the address fields. You will also loose some speed as the lda instruction takes an extra cycle if the address +X crosses a page boundary (I don't think the sta takes an extra cycle though). In this case, you should move the first few bytes seperately to bring the load address up to a page boundary, then use this type of routine for the rest.

If my memory serves correct, this routine takes 4+5+2+3=14 cycles for each byte on the inner loop, which is what really counts. total cost is 2+4+2+4+2+2+4*(256*(4+5+2+3)-1+6+6+2+3)-1=14415 I think.

Which is 7.2 milliseconds. Hmm, not too bad....

This is if the sta takes a consistant 5 cycles, which may be wrong, so adjust accordingly.... (If it's not 5 cycles, it's 4).

Dave.


Unrolling loops
Date: Thu, 17 Jun 93 09:48:19 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: Unrolling loops

Mik Davis wrote:

>  I need a *fast* routine to move 1024 bytes of RAM across the memoru of my >machine. Must be compatible with all the 6502 based machine (B, B+, master etc)

David Andrew Sainty replied:

>Fastest method is using an index on self modifying absolute address >instructions. eg.

>

>lda#start DIV256:sta adr+2

>lda#end DIV256:sta adr2+2

>ldy#3:ldx#0

>.adr lda &FF00,X

>.adr2 sta &FF00,X

>inx:bne adr

>inc adr+2

>inc adr2+2

>dey:bpl adr

>

>This works fine if the blocks you want to move are on page boundaries.

>If they are not, it still works but you have to program both bytes of the >address fields. You will also loose some speed as the lda instruction takes

>an extra cycle if the address +X crosses a page boundary (I don't think

>the sta takes an extra cycle though). In this case, you should move the

>first few bytes seperately to bring the load address up to a page

>boundary, then use this type of routine for the rest.

>

>If my memory serves correct, this routine takes 4+5+2+3=14 cycles for

>each byte on the inner loop, which is what really counts. total cost

>is 2+4+2+4+2+2+4*(256*(4+5+2+3)-1+6+6+2+3)-1=14415 I think.

>

>Which is 7.2 milliseconds. Hmm, not too bad....

>

>This is if the sta takes a consistant 5 cycles, which may be wrong, so

>adjust accordingly.... (If it's not 5 cycles, it's 4).

>

>Dave.

This can be sped up still further by copying more bytes each time through the loop. This takes more program bytes, but more time is spent transferring memory, and less is spent looping. Also, there is not need to use Y:

ldx#start DIV256:stx adr1+2

inx:stx adr3+2

inx:stx adr5+2

inx:stx adr7+2

ldx#end DIV256:stx adr2+2

inx:stx adr4+2

inx:stx adr6+2

inx:stx adr8+2

ldx#0

.adr1 lda &FF00,X

.adr2 sta &FF00,X

.adr3 lda &FF00,X

.adr4 sta &FF00,X

.adr5 lda &FF00,X

.adr6 sta &FF00,X

.adr7 lda &FF00,X

.adr8 sta &FF00,X

inx:bne adr

If daves memory serves him right about timing issues...

Inner loop: 4+5+4+5+4+5+4+5+2+3=41 cycles for four bytes.

Total cost is: 2+4+2+4+2+4+2+4+2+4+2+4+2+4+2+4+2+256*41 = 10546

Which is 5.26 milliseconds....

Matthew

matthew@tadtec.co.uk


Unrolling loops1
Date: Thu, 17 Jun 1993 23:45:36 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: matthew@tadtec.co.uk

Subject: Unrolling loops

   From: matthew@tadtec.co.uk (Matthew Sweet)

   David Andrew Sainty replied:

   >Fastest method is using an index on self modifying absolute address

   >instructions. eg.

   >

   >lda#start DIV256:sta adr+2

   >lda#end DIV256:sta adr2+2

   >ldy#3:ldx#0

   >.adr lda &FF00,X

   >.adr2 sta &FF00,X

   >inx:bne adr

   >inc adr+2

   >inc adr2+2

   >dey:bpl adr

   >

   >Which is 7.2 milliseconds. Hmm, not too bad....

   >

   >This is if the sta takes a consistant 5 cycles, which may be wrong, so

   >adjust accordingly.... (If it's not 5 cycles, it's 4).

This can be sped up still further by copying more bytes each time through the loop. This takes more program bytes, but more time is spent transferring memory, and less is spent looping. Also, there is not need to use Y:

   ldx#start DIV256:stx adr1+2

   inx:stx adr3+2

   inx:stx adr5+2

   inx:stx adr7+2

   ldx#end DIV256:stx adr2+2

   inx:stx adr4+2

   inx:stx adr6+2

   inx:stx adr8+2

   ldx#0

   .adr1 lda &FF00,X

   .adr2 sta &FF00,X

   .adr3 lda &FF00,X

   .adr4 sta &FF00,X

   .adr5 lda &FF00,X

   .adr6 sta &FF00,X

   .adr7 lda &FF00,X

   .adr8 sta &FF00,X

   inx:bne adr

   If daves memory serves him right about timing issues...

   Inner loop: 4+5+4+5+4+5+4+5+2+3=41 cycles for four bytes.

   Total cost is: 2+4+2+4+2+4+2+4+2+4+2+4+2+4+2+4+2+256*41 = 10546

   Which is 5.26 milliseconds....

Quite right! Of course, you can always speed things up by unravelling loops, but this particular case suits unravelling so well I was stupid to miss it!

At least I got the timing right! :-)

LDA abs,X is 4 cycles (+1 if you know what)

STA abs,X is 5 cycles in all cases.

Dave.


Acorn Address
Date: Wed, 23 Jun 93 09:20:17 BST

From: ajcd@dcs.edinburgh.ac.uk

To: bbc-list@ohm.york.ac.uk

Subject: Acorn Address

Does anyone have Acorn's current UK address and phone number?

a.


Re: Unrolling loops & fast routines
Date: Wed, 23 Jun 93 12:42:17 +0100

From: Mik Davis <davism@uhura.aston.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Unrolling loops & fast routines

>I wrote:

>>  I need a *fast* routine to move 1024 bytes of RAM across the memoru of my

>>machine. Must be compatible with all the 6502 based machine (B, B+, master etc)

>>David Andrew Sainty replied:

>>Fastest method is using an index on self modifying absolute address >>instructions. eg.

  [code deleted]

>>This works fine if the blocks you want to move are on page boundaries.

>>If they are not, it still works but you have to program both bytes of the

>>address fields. You will also loose some speed as the lda instruction takes

>>an extra cycle if the address +X crosses a page boundary (I don't think

>>the sta takes an extra cycle though). In this case, you should move the

>>first few bytes seperately to bring the load address up to a page

>>boundary, then use this type of routine for the rest.

>>Dave.

  Someone else replied:  [sorry, I deleted the header]

>

>This can be sped up still further by copying more bytes

>each time through the loop. This takes more program bytes,

>but more time is spent transferring memory, and less

>is spent looping. Also, there is not need to use Y:

>

>ldx#start DIV256:stx adr1+2

>inx:stx adr3+2

>inx:stx adr5+2

>inx:stx adr7+2

>ldx#end DIV256:stx adr2+2

>inx:stx adr4+2

>inx:stx adr6+2

>inx:stx adr8+2

>ldx#0

>.adr1 lda &FF00,X

>.adr2 sta &FF00,X

>.adr3 lda &FF00,X

>.adr4 sta &FF00,X

>.adr5 lda &FF00,X

>.adr6 sta &FF00,X

>.adr7 lda &FF00,X

>.adr8 sta &FF00,X

>inx:bne adr

>

>If daves memory serves him right about timing issues...

>Inner loop: 4+5+4+5+4+5+4+5+2+3=41 cycles for four bytes.

>Total cost is: 2+4+2+4+2+4+2+4+2+4+2+4+2+4+2+4+2+256*41 = 10546

  Great, now I'm no expert in this area, so could someone please send me the above code set up to work anywhere in memory. (Dave mentioned something about page boundaries earlier?). The destination will always be the screen display RAM (yes, I'm shifting MODE 7 screens) so &7C00 to &7FFF. The source address could potentially be anywhere as it is just DIMed in BASIC.

  Thanks, Mik

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk ------------------------------------------------------------------------------- "There are two ways of disliking poetry; one way is to dislike it, the

other is to read Pope."

-- Oscar Wilde


Re: Unrolling loops & fast routines1
Date: Thu, 24 Jun 93 09:54:47 BST

From: matthew@tadtec.co.uk (Matthew Sweet)

To: bbc-list@ohm.york.ac.uk

Subject: Re: Unrolling loops & fast routines

Mik,

You wrote:

>  Great, now I'm no expert in this area, so could someone please send me

>the above code set up to work anywhere in memory. (Dave mentioned something

>about page boundaries earlier?). The destination will always be the screen

>display RAM (yes, I'm shifting MODE 7 screens) so &7C00 to &7FFF. The source

>address could potentially be anywhere as it is just DIMed in BASIC.

Mik,

The only way to get the routine as fast as the above is to use it to

copy from and to page aligned buffers. The easiest way to guarantee

that you can do this is to DIM more memory than you need, and use

another variable as your base:

DIM BufferSpace% &4ff

BufferStart%=(BufferSpace%+&ff) AND &100

If you _always_ want to copy from the same buffer to screen memory, then the preamble at the start of the routine can be reduced, making the code:

copy_buffer_to_screen:

ldx #0

.loop	lda BufferStart%,X

sta &7c00,X

lda (BufferStart%+&100),X

sta &7d00,X

lda (BufferStart%+&200),X

sta &7e00,X

lda (BufferStart%+&300),X

sta &7f00,X

inx

bne loop

rts

This code fragment is 30 bytes long, and contains no absolute jumps, therefore you should be able to assemble it starting at BufferSpace%, and relocate it to BufferStart%+&400 if BufferStart%-BufferSpace% < 30.

Note:

1	Your code will not work if you are using a second processor.

2	Your code will give strange results if the screen has H/W

scrolled since the last time the screen was cleared.

Hope that this has been helpful!

Matthew


Unrolling loops & fast routines2
Date: Fri, 25 Jun 1993 07:28:24 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Unrolling loops & fast routines

   Date: Thu, 24 Jun 93 09:54:47 BST

   From: matthew@tadtec.co.uk (Matthew Sweet)

   Mik,

   The only way to get the routine as fast as the above is to use it to

   copy from and to page aligned buffers. The easiest way to guarantee

   that you can do this is to DIM more memory than you need, and use

   another variable as your base:

   DIM BufferSpace% &4ff

   BufferStart%=(BufferSpace%+&ff) AND &100

Of course, we all knew Matthew really meant AND &FF00 here... :-)

   This code fragment is 30 bytes long, and contains no absolute jumps,

   therefore you should be able to assemble it starting at BufferSpace%,

   and relocate it to BufferStart%+&400 if BufferStart%-BufferSpace% < 30.

Hmmm, nice little way around the basic thing.....

However, I wonder if the super-fast transfer is really required at all?

Making it transfer from an arbitrary address will be perhaps 400 cycles slower on average, but that's NOT very long! (especially if the bulk of your code is in basic...)

If you have multiple screens and are DIMing lots of screen buffers,allocating an extra 256 bytes each time is going to get expensive!

Note also that the mode 7 screen is only 40x25 bytes, which is 24 bytes less than 1k. Not only can you dim less than 1k per screen, but you can also transfer less and gain speed that way (Note that this is a little messy, you need two loops transferring 3 pages concurrently, and the 4th page in a 2nd loop).

Dave.


Unrolling loops & fast routines3
Date: Fri, 25 Jun 93 11:11:40 BST

From: "M.J.Ebourne" <M.J.Ebourne@southampton.ac.uk>

To: bbc-list@ohm.york.ac.uk (Beeb mailing list)

Subject: Unrolling loops & fast routines

> If you have multiple screens and are DIMing lots of screen buffers,

> allocating an extra 256 bytes each time is going to get expensive!

If he's got multiple screens he only needs one dim, and so at worst loses 255 bytes.

My personal prefered way would be to lower HIMEM and allocate yourself the memory. That is guaranteed to be in the same place all the time, and be page aligned. Much more sensible.

> Note also that the mode 7 screen is only 40x25 bytes, which is 24 bytes

> less than 1k. Not only can you dim less than 1k per screen, but you

> can also transfer less and gain speed that way (Note that this is a

> little messy, you need two loops transferring 3 pages concurrently, and

> the 4th page in a 2nd loop).

Indeed, but it would not NECESSARILY be quicker. Its worth counting the cycles to make sure. Also, to save 24 bytes requires a lot of messing around for very little gain.

Also the fact that the screen is being copied in several different places simultaneously makes it look smoother because you cannot see one bit appearing before another.

--

Martin Ebourne                             Email: mje@soton.ac.uk

Electronics, Southampton University


Re: Unrolling loops & fast routines2
From: Mik Davis <davism@uhura.aston.ac.uk>

Date: Fri, 25 Jun 93 15:29:14 +0100

To: bbc-list@ohm.york.ac.uk

Subject: Re: Unrolling loops & fast routines

>> If you have multiple screens and are DIMing lots of screen buffers,

>> allocating an extra 256 bytes each time is going to get expensive!

>>If he's got multiple screens he only needs one dim, and so at worst loses

>255 bytes.

  No, I only have one buffer. I load the data from disc into the buffer then transfer it to the screen afterwards

>

>My personal prefered way would be to lower HIMEM and allocate yourself the >memory. That is guaranteed to be in the same place all the time, and be page >aligned. Much more sensible.

>

  It works now. In this case I'm not too worried about wasting memory so the extra RAM used by my method is fine

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk ------------------------------------------------------------------------------- "Wagner's music is better than it sounds."

-- Mark Twain


Unrolling loops & fast routines4
Date: Sat, 26 Jun 1993 02:57:55 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Unrolling loops & fast routines

   Date: Fri, 25 Jun 93 11:11:40 BST

   > If you have multiple screens and are DIMing lots of screen buffers,

   > allocating an extra 256 bytes each time is going to get expensive!

   If he's got multiple screens he only needs one dim, and so at worst loses

   255 bytes.

This much is true. But still... waste is waste....

   My personal prefered way would be to lower HIMEM and allocate yourself the

   memory. That is guaranteed to be in the same place all the time, and be page

   aligned. Much more sensible.

Yes, it is.

   > Note also that the mode 7 screen is only 40x25 bytes, which is 24 bytes

   > less than 1k. Not only can you dim less than 1k per screen, but you

   > can also transfer less and gain speed that way (Note that this is a

   > little messy, you need two loops transferring 3 pages concurrently, and

   > the 4th page in a 2nd loop).

   Indeed, but it would not NECESSARILY be quicker. Its worth counting the

   cycles to make sure. Also, to save 24 bytes requires a lot of messing around

   for very little gain.

Hmm, I thought I'd worked it out to be cheaper, perhaps not. In that case, you

can still write the whole 1k block, but only allocate 1k-24 bytes per screen.

The 24 bytes will still be saved, and whatever happens to be there will never

be seen.

   Also the fact that the screen is being copied in several different places

   simultaneously makes it look smoother because you cannot see one bit appearing

   before another.

I was assuming the code would be synced with the screen vsync, in which case

teh code is FAR too fast for the updates in different places to be noticed.

If the screen copy is not synced, it'll look messy WHATEVER copy scheme

memory->screen is used...

D.


Re: Unrolling loops & fast routines3
From: Mik Davis <davism@uhura.aston.ac.uk>

Date: Thu, 24 Jun 93 14:22:59 +0100

To: bbc-list@ohm.york.ac.uk

Subject: Re: Unrolling loops & fast routines

>Mik,

>

>The only way to get the routine as fast as the above is to use it to

>copy from and to page aligned buffers. The easiest way to guarantee

>that you can do this is to DIM more memory than you need, and use

>another variable as your base:

  Yes, I realised last night that it was far simpler to do

DIM buffer_space% 2048

buffer%=buffer_space%-1

REPEAT

buffer%=buffer%+1

UNTIL buffer% MOD 256 =0

  than to mess about with multi-byte arithmetic

>If you _always_ want to copy from the same buffer to screen memory,

>then the preamble at the start of the routine can be reduced, making

>the code:

>Note:

>1	Your code will not work if you are using a second processor.

  Yes, I'm working on that one...

>2	Your code will give strange results if the screen has H/W

>	scrolled since the last time the screen was cleared.

  It won't have, I can guarantee that

>Hope that this has been helpful!

  Yes, Thanks, my software is working fine now.

-------------------------------------------------------------------------------

        Mik Davis at Aston University. E-Mail davism@uhura.aston.ac.uk ------------------------------------------------------------------------------- May a Misguided Platypus lay its Eggs in your Jockey Shorts


Arithmetic routines
Date: Fri, 25 Jun 93 13:44:31 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Arithmetic routines

Has anyone got a good set of signed and unsigned 32 bit integer multipication,  division and modulus routines they can let me have.

I need these to complete a C compiler I've been working on. It's got a number of bugs still, but it generates (very bad) 6502 code from full ansi C ( minus  floating point - anyone got those routines?). I just added structures this  morning, so once I've got some arithmetic routines I'll put out a beta version  on shiraz. It can't handle multiple files yet eiter, but I can fix that easily  enough once I've debugged the rest of the system.

I've got a couple of multipication routines (in books) that I could use, but I'm too lazy to type them in, and they're not quite suitable anyway. Idealy the  routine should NOT calculate anything outside the 32 bits ie a 64 bit result  would be just thrown away.

The bad news is that I the current version is VERY unlikely to be able to  compile itself, as the code produced is far too big - you'll need a unix or  decent(!) pc to host it from. However I haven't started doing any optimising  yet so I expect to be able to improve things dramatically.

Ian


Re: Arithmetic routines
Date: Fri, 25 Jun 1993 17:46:16 +0100 (BST)

From: "John K Nicoll" <jkn>

To: ian@ohm.york.ac.uk (I Stephenson)

Subject: Re: Arithmetic routines

According to I Stephenson:

>

> Has anyone got a good set of signed and unsigned 32 bit integer multipication,

> division and modulus routines they can let me have.

> [...]

I have a copy of

(i) the Small-C compiler for the BBC - can't remember what library supprot this has - and

(ii) the Manx PC C X-compiler. I don't know what run-time support you get with this - i'll bring it in next week & have a look

john N


6502 C compiler
Date: Wed, 30 Jun 93 13:05:17 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: 6502 C compiler

I've completed a first release of my C compiler, and have placed it on shiraz.

I expect there are a number of bugs in it, so if anyone can help track them  down I'd appreciate it.

It implements full ansi C (minus floating point, libraries, preproceccor and  seperate compilation), but requires a seperate host on which to run.

The code generated is currently VERY inefficient, but its more imprtant to get  the bugs found now, while the code generator is simple, rather than making it  complex, then trying to fix it.

Any comments would be appreciated

Ian


TequilaComm3
Date: Fri, 2 Jul 1993 08:37:00 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: TequilaComm

As of yesterday, Tequilacomm can emulate MNP 2. MNP2 is identical to MNP3 in all by framing method, and as I am still waiting for the vital component to arrive here that will allow me to support MNP3 and LAPM, it seemed sensible to implement MNP2 first, though I wasn't originally going to bother. My implementation also supports the enhancements of MNP4, so it's a sort of hybrid. The modems here that actually support MNP2 also seem to handle these enhancements on top.

So now I can call modems AND have the phone off the hook! (Although things slowed down just TOO much when I put the receiver in front of my stereo!) :-)

I would throw MNP5 on top of it, but don't have information on it. I'm going to TRY and put V.42bis compression on top, but this is unlikely to work with many modems (But it's all part of the grand plan of full V.42/V.42bis compatability anyway).

The code so far is around 2.5k long, and takes the form of a sideways rom image in sideways ram. All workspace is contained in the ram bank (And of course you loose 16k of scrollback space). The upgrade from MNP to LAPM will be relatively painless, most of the code written so far will be portable to the LAPM environment.

This has probably been one of the fastest pieces of coding I've done, start to finish time of less than a week (Although that was pretty intensive work, and varsity is currently out...). So once I get hold of the hardware things should get really interesting pretty quick...

Dave.


Mouse-driven s/w
Date: Fri, 2 Jul 93 12:03:52 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Mouse-driven s/w

Has anyone got any good mouse driven software they can let me have?

A lecturer round here wants to demo a mouse replacement device thats been built  to emulate and AMX style mouse. Unfortuntly he hasn't got much software to use  with it.

I've got the AMX Art package, but anything else would be extremly usefull. The  idea is to show how software can be operated by disabled users, so stuff that  avoids the keyboard is preferable.

Ian


Beeb graphics
Date: Tue, 6 Jul 1993 08:35:34 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Beeb graphics

I was thinking, what Tequilacomm really misses, or where it misses out MOST over other machines, is lack of colour. And of course this spills over to applications like GIF displaying etc.

So I would quite like to have a look at improving the situation.

Fundamentally, I want a simple character by character foreground/background colour setting, with intensity (bold on/off) and probably flashing too (with comms in mind). I'm looking at a very inexpensive system, sitting between the RGB output and monitor (i.e. no composite or TV

support).

This system MAY be extendable to full pixel by pixel colour setting, or even half pixel by half pixel, to double horizontal resolution (this all sort of depends on how easy a task it is to lock onto the RGB data stream from the beeb, which is what I'm going to look at first).

Other options are there.... A complete external video system, which would obviously be more expensive, and not quite the "simple upgrade for a colour terminal" job, this would really need using (gif viewers and stuff).  And then there is always the option of simply taking a standard IBM video card and interfacing that to the beeb.

Anybody else interested in looking at this, or interested in the results of what I try? And how would you want to use the system? (is just comms type colour ok?)

Probably most important, how much is it worth? (i.e. do you like the idea quite a lot, but only $20 lot?)

I think a character based colour system may be feasable for around $20 parts (Not including connectors! :-). My design will probably be most influenced by what I am able to recycle out of old circuits I've picked up, so I may never find out a firm price (I always hope that it will cost me nothing! :-)

Dave.


Colour Graphics
Date: Tue, 6 Jul 93 09:03:55 +0200

From: stjohn@poly.polytechnique.fr (Chris StJohn)

To: bbc-list@ohm.york.ac.uk

Subject: Colour Graphics

Re: David.Sainty's message about Beeb Colour

Yes. Over the past couple of months I've been looking into what sort of colour support could be put on the side of a beeb. The options are:

(1) Piggy-back the 6845 with an additional memory board to give true colour. This runs into problems mostly because of the way the 6845 is organised and the bandwidth required. Might have to array 32x16k DRAMs which would be fastiduous (not least as 16k Ds are comparitively expensive these days!).

(2) Build a board which goes into the 1 MHz bus or some other port and which has a controller on-board. There are a few (very few) single-chip solutions for display circuitry. If anybody is interested in details, watch sci.electronics where soon I'll summarize the question I posted a week ago.

(3) Do what everyone else does and build using TTL or PLAs.

The bandwidth required is 1 pixel every 150ns, which with modern memory is easy. I have designed a tentative circuit which will display 320x204x256colours using very cheap 4x64k DRAMs. (L2 each - need 2 of 'em). This circuit didn't arbitrate the bus, but with modern RAM accesses at 80ns there's no reason why it would be impossible to build a zero-contention video card.

The biggest headache is the sync stuff. Digital electronics I can do, but it's this analog sync lark that freaks me. I've got a circuit of a video board which uses only TTL and another which uses the 6845 (1983 vintage!) so I'm hoping to be able to work out that part. Recommendations for books would be appreciated.

Any hardware gurus out there who can help me/us ??

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_)     "He that breaks a thing to find out what it

---------------       is has left the path of wisdom" -- Gandalf


Colour Graphics1
Date: Wed, 7 Jul 1993 02:17:00 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Colour Graphics

   Date: Tue, 6 Jul 93 09:03:55 +0200

   From: stjohn@poly.polytechnique.fr (Chris StJohn)

   Re: David.Sainty's message about Beeb Colour

   Yes. Over the past couple of months I've been looking into what sort of colour

   support could be put on the side of a beeb. The options are:

(1) Piggy-back the 6845 with an additional memory board to give true colour.   This runs into problems mostly because of the way the 6845 is organised and   the bandwidth required. Might have to array 32x16k DRAMs which would be   fastiduous (not least as 16k Ds are comparitively expensive these days!).

(2) Build a board which goes into the 1 MHz bus or some other port and which   has a controller on-board. There are a few (very few) single-chip solutions for display circuitry. If anybody is interested in details, watch sci.electronics where soon I'll summarize the question I posted a week ago.

I was hopeing to avoid messing about inside the computer itself, but have come to the conclusion that unless a complete seperate CRTC circuit is used, there's no other feasable way of locking onto the original video signal.

But for anything serious, I'd throw idea 1. The colour generation is the job of the video ULA, so at the very least that'd come into the picture too.

The bandwidth required is 1 pixel every 150ns, which with modern memory is easy. I have designed a tentative circuit which will display 320x204x256colours using very cheap 4x64k DRAMs. (L2 each - need 2 of 'em). This circuit didn't arbitrate the bus, but with modern RAM accesses at 80ns there's no reason why it would be impossible to build a zero-contention video card.

Hmmm, how are you looking at accessing the video memory? If through the 1MHz bus, accesses will be far and few.... What I was playing about with today (at the paper stage) was as bad as updating the external video ram during the horizontal sync! :-)

(That's obviously too slow for high res, one update per scan line)

The biggest headache is the sync stuff. Digital electronics I can do, but it's this analog sync lark that freaks me.

Anything cooperating with the old circuitry is going to be messy with the sync bit! With proper colour/high res in mind, I think a whole new circuit is needed, which avoids the messy sync problems (And leaves your machine intact!)

   Recommendations for books would be appreciated.

   Any hardware gurus out there who can help me/us ??

Ditto!


Colour Graphics2
Date: Thu, 8 Jul 1993 03:33:27 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Colour Graphics

   Date: Tue, 06 Jul 93 20:23:48 +0200

   From: stjohn@poly.polytechnique.fr

>>But for anything serious, I'd throw idea 1. The colour generation is the

>>job of the video ULA, so at the very least that'd come into the picture too.

>Ah, but the ULA can't cope with anything but the standard 8 colours (or can it???)

Quite true, I misinterpreted what you were suggesting.

>>Hmmm, how are you looking at accessing the video memory? If through the 1MHz

>>bus, accesses will be far and few.... What I was playing about with today

>>(at the paper stage) was as bad as updating the external video ram during the

>>horizontal sync! :-)

>So far the circuit I designed hooked up to the Vsync and Hsync outputs of the

>6845. Remember that (at least on my board) this is socketed, so inserting a

>board under it would be easy. Also, that way the beeb still generates the sync

>and you can use a few op-amps to sum the beeb screen with the new RGB. Like

>that you only need 1 monitor and no fiddling to switch modes.

I think any useful system must allow switching between the two screen drivers. Summing is an interesting idea... But the old outputs are only TTL level anyway, so switching isn't a big deal....

You must have a model B. The Master 6845 is soldered in. :-(

>The access would take place during frame blanking (which is about half the

>time) so it wouldn't be fast.

>

>Anyway, all this is academic as I'm looking at a chip solution from Intel/NEC -

>the 82716. A guy at ICL told me about it, and it seems to do everything more

>or less. It has minimal sprite and window functionality, outputs RGB (but I

>don't know what sort of standard yet) and just needs a data bus and some DRAM

>plugged into it. (this is what he's been telling me - the Ecole doesn't have

>an electronics lab so I can't get any data books to see for myself yet. Waiting

>'till I'm back in Cambridge next week)

Hmmm, what's the chance of my university having info on it! Not very likely!

:-( I'll have a look too though.

>To sum it all up, apparently a company in the UK is happily selling these

>things at L2 each (!!).

Hmmm, not bad!

>How would your idea go about getting the bandwidth out of the memory? I'm looking

>to just pump the 8 bit wide data bus to a DAC and use the relatively high speed

>of the modern memory instead of the more conventional shift register approach.

>This is mainly because I remember what a pain programming raster blits on the

>Atari is due to its screen model (in fact, the beeb must be worse for non-aligned

>raster blits). Also, as I said it's far cheaper to buy a couple of 4464s than

>32 4116s.

Well, bandwidth really isn't a hassle yet with me, as I'm only wanting to

read data on a per-character basis.

>So... PLEASE tell me more about your ideas !!!

Well, character based attributes are first and foremost my priority. This

avoids most of your problems. I was also hopeing to design something that

most people could make relatively easilly.

There is an intensity line on my monitor, I was going to use that (This may

mean my monitor is TTL input, which would be bad news!).

Character addressing is easy, with (off the 6845) the Character clock line to address characters, the Display enable line to both count rastor lines and indicate the display start position, and Vsync to reset.

I could probably use Hsync instead of DE, and get both off the RGB port, but as I need CCLK anyway off the 6845, I may as well get the other two!

Cost: a couple of ripple counters, a few latches, couple of multiplexers, and a smidgeon of memory. Not bad for the pocket! Might even get it to fit inside the computer!

I haven't yet put any thought to more complex design, but I think anything serious should have its own controller, rather than trying to tack onto the resident 6845. An external controller even allows the option of TWO screens (Nice if you can afford it! :-)

Dave.


C-compiler beta release
Date: Wed, 7 Jul 93 14:42:00 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: C-compiler beta release

If anyone picked up a copy of my C compiler from shiraz.ohm.york.ac.uk, then I  sugguest they have a look at the new version.

Its got better libraries, numerous bug fixes, and produces shorter, faster  code!

Any feedback is appreciated

Ian


Colour Graphics3
Date: Thu, 8 Jul 1993 11:23:35 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Colour Graphics

On the hardware front, I've just found out something rather unusual! The video character clock is synced with the system clock! I always thought the 17.7345 MHz crystal was the video crystal, Does anyone know what that's actually for? (Serial port?)

This puts a whole new perspective on the sync problem, just derive the video clock from the 1MHz signal on the 1MHz bus!

Unfoortunately, the clock phase is not very nice. You only get one transition per character in 80 column modes, and the transition is precisely on the half character mark! Can't get much worse! :-) This appears to be the case on Master and model B alike. A little problem....

Does anybody have the pinout for the tube connector? That no doubt will have a faster clock line on it, but I don't have information on it.

There is an 8MHz clock on the cartridge socket on the master, that would solve the problem for master users, but not model B'ers...


Colour Graphics4
Date: Fri, 9 Jul 93 19:15:13 BST

From: ajcd@dcs.edinburgh.ac.uk

To: David.Sainty@comp.vuw.ac.nz

Subject: Colour Graphics

>From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

>

>Does anybody have the pinout for the tube connector? That no doubt will have

>a faster clock line on it, but I don't have information on it.

The most likely looking signal in the Tube docs is:

Pin     Name    Type

19      HPHI2   TTL input 1 LS load

a.


Colour Graphics5
Date: Sun, 11 Jul 1993 06:28:13 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Colour Graphics

>From: ajcd@dcs.edinburgh.ac.uk

>Date: Fri, 9 Jul 93 19:15:13 BST

>>From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

>>

>>Does anybody have the pinout for the tube connector? That no doubt will have

>>a faster clock line on it, but I don't have information on it.

>

>The most likely looking signal in the Tube docs is:

>

>Pin     Name    Type

>19      HPHI2   TTL input 1 LS load

I presume type is the type of the HPHI2 line, not its drive capacity, in which case it's an input, so not directly at least what we want (Though if it is some sort of system clock replacement input, it'd be just the ticket!)

Could you post the other pins too? Most will be required if the Tube were used....


BASIC V -> II or IV
Date: Thu, 8 Jul 93 15:45:08 BST

From: Grimthorpe <stj@computer-science.manchester.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: BASIC V -> II or IV

I don't suppose anyone knows of a utility that can convert BASIC V files to BASIC II or IV?

  I'm trying to convert a program I have for the Arc to run on my ACW, but unfortunately it uses most of the new features. I don't need anything that attempts to fix SWI's, as there is only 1 in the program, and I know what to replace it with.

  Adrian StJohn ---------------------------------------------------------------------

 Bad spellers of the world untie


Tube connections (was RE: colour Graphics)
Date: Mon, 12 Jul 1993 12:50:15 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: jkn@ohm.york.ac.uk

Subject: Tube connections (was RE: colour Graphics)

>From: "John K Nicoll" <jkn@ohm.york.ac.uk>

>Date: Sun, 11 Jul 1993 20:42:55 +0100 (BST)

>don't you guys have the Beeb circuit diagram? I'm amazed!

Definately wish I did!

>Anyway, here's something I dug out of the vault...

>40 way IDC connector.

>pins 1,3,...,27,29 - 0V

>pins 31,33,35,37,39 - 5V

>pin	2 - R/N	OP

>	   4 - 2MHZ E 	OP

>	   6 - NIRQ	IP

>	   8 - NTUBE	OP

>	   10 - NRST	IP

>	   12 - D0

>	   14 - D1

>	   ...

>	   26 - D7

>	   28 - A0

>	   30 - A1

>	   32 - A2

>	   34 - A3

>	   36 - A4

>	   38 - A5

>	   40 - A6

>

>hope this helps

>	   john N

Certainly does! Pin 4 is the clock we need. With 7 address lines, that should be enough to map some control registers to addresses not used by 2nd processors, so it needn't be the case that you could only have one or the other plugged in. Strange though, I assume the NTUBE line indicates an address space of 127 bytes is being addressed, within Sheila?

Oh, just noticed something else... NRST is down as an input here, is that a typo? I'd expect it to be an output... (though plausably could act as an input too)

Dave.


Re: Tube connections (was RE: colour Graphics)1
Date: Mon, 12 Jul 93 11:21:43 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Tube connections (was RE: colour Graphics)

>Certainly does! Pin 4 is the clock we need. With 7 address lines, that

>should be enough to map some control registers to addresses not used by

>2nd processors, so it needn't be the case that you could only have one or

>the other plugged in. Strange though, I assume the NTUBE line indicates

>an address space of 127 bytes is being addressed, within Sheila?

I have before me a (slightly illicit) circuit diagram for the Acorn Tube  Spiltter. This (officially non-existant) device (which is curently sitting here  looking dead) plugs into the Tube, and allows two 2nd processors to be attached, and switched by software.

This tells me that A0,1 and 2 are passed on the co-prcessor. RST is an output  only (its buffered and switched by this circuit). A3 and 4 are used by the tube  switcher, along with HCS (the name used for NTube). Pins 38 and 40 (A5+6 are not connected).

In addtion to the 8 datalines, the only other pins used are Phi2 (4) and  R/nW   (2). Apart from the data lines, all are output only.

I was actually planning to start playing around with this circuit today (I just  can't get mine to work!), so I'll report anything intersting.

Ian


Re: Tube connections (was RE: colour Graphics)2
Date: Tue, 13 Jul 1993 08:18:29 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Tube connections (was RE: colour Graphics)

>Date: Mon, 12 Jul 93 11:21:43 +0100 (BST)

>From: "I Stephenson" <ian@ohm.york.ac.uk>

>I have before me a (slightly illicit) circuit diagram for the Acorn Tube

>Spiltter. This (officially non-existant) device (which is curently sitting here

>looking dead) plugs into the Tube, and allows two 2nd processors to be

>attached, and switched by software.

>This tells me that A0,1 and 2 are passed on the co-prcessor. RST is an output

>only (its buffered and switched by this circuit). A3 and 4 are used by the tube

>switcher, along with HCS (the name used for NTube). Pins 38 and 40 (A5+6 are

>not connected).

Output _from_ the computer?

I assume it suffices to isolate the Ntube on a second processor to disable it.... (Hmmm, and NIRQ I guess).

So, this seems to indicate only the low 8 locations are required by TUBE hardware. Does the splitter ensure splitter switching writes don't make it to the second processor? (What I'm really asking is, if a write is make to a second processor above those bottom 8 locations, does it ignore it, or might it panic?)

>In addtion to the 8 datalines, the only other pins used are Phi2 (4) and  R/nW

>(2). Apart from the data lines, all are output only.

>I was actually planning to start playing around with this circuit today (I just

>can't get mine to work!), so I'll report anything intersting.

How many second processors have you got!? :-)

Dave.


Re: Tube connections (was RE: colour Graphics)3
Date: Tue, 13 Jul 93 10:28:36 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Tube connections (was RE: colour Graphics)

>Output _from_ the computer?

Yeah - Everything is an output FROM the host except the data lines.

>I assume it suffices to isolate the Ntube on a second processor to disable

>it.... (Hmmm, and NIRQ I guess).

More or less - NIRQ doesn't go through the tube (otherwise everything would get  VERY confused). IRQ's are generated independanly on the 2P when data is written  to the tube hardware(ish). The circuit (in addition to zapping NTube) also

holds the reset line low on the disabled processor. All the lines are buffered,  as they now need to drive a greater load.

(though bear in mind that I can't get this circuit to work! - it seems to be  doing sensible things when I test it here at work, but when I take it home and  plug it in it just dies :-().

>So, this seems to indicate only the low 8 locations are required by TUBE

>hardware. Does the splitter ensure splitter switching writes don't make it

>to the second processor?

Yes - NTube is only passed on when A3 and A4 are low.

The next 8 locations are used by the tube splitter itself to switch processors,  but provided A4 is high your in the clear.

You probably want to check out the Master circuit diagrams if you can, as it can switch between internal and external processors. It probably works almost  identically (this circuit is described as the ABM tube splitter, so it predates  the Master).

>How many second processors have you got!? :-)

2 - a 6502 and a 32016.

Ian


Re: Tube connections (was RE: colour Graphics)4
Date: Wed, 14 Jul 1993 13:18:33 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: ian@ohm.york.ac.uk

Subject: Re: Tube connections (was RE: colour Graphics)4

Date: Tue, 13 Jul 93 10:28:36 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

>>I assume it suffices to isolate the Ntube on a second processor to disable

>>it.... (Hmmm, and NIRQ I guess).

>

> More or less - NIRQ doesn't go through the tube (otherwise everything would get

> VERY confused). IRQ's are generated independanly on the 2P when data is written

> to the tube hardware(ish). The circuit (in addition to zapping NTube) also

> holds the reset line low on the disabled processor. All the lines are buffered,

> as they now need to drive a greater load.

But what about the other direction? Are the tube registers polled on the IO processor? I always assumed that they were tested on IRQ, in fact, it seems strange that Tube IRQ is an output, as the IRQ line is used for all the hardware that the 2nd P shouldn't care about. Are you sure about that??

> You probably want to check out the Master circuit diagrams if you can, as it

> can switch between internal and external processors. It probably works almost

> identically (this circuit is described as the ABM tube splitter, so it predates

> the Master).

Wish I could.... (though with all those custom Acorn chips on the motherboard, tracing the circuit would be real tricky!


Re: Tube connections (was RE: colour Graphics)5
Date: Tue, 13 Jul 93 12:50:06 +0200

From: stjohn@poly.polytechnique.fr

To: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

Subject: Re: Tube connections (was RE: colour Graphics)

>I assume it suffices to isolate the Ntube on a second processor to disable

>it.... (Hmmm, and NIRQ I guess).

Yes. I believe at least the 32016 2nd processor does exactly this. On my ACW there's a little toggle switch behind the keyboard that switches in the tube.

>So, this seems to indicate only the low 8 locations are required by TUBE

>hardware. Does the splitter ensure splitter switching writes don't make it

>to the second processor? (What I'm really asking is, if a write is make

>to a second processor above those bottom 8 locations, does it ignore it,

>or might it panic?)

Pandora won't. I've disassembled all the importants parts of it so I can guarantee that in general it won't panic. If you want to make extra sure, see the new AUG which details the Tube I/O and protocol.

Be careful with NMI because Pandora at least uses the NMI as a sort of software DMA. After a disk I/O the beeb sends NMIs to the 32016 with data in the Tube ULA. This is how data is transfered transparently into the second processor. If you start fiddling with them, then expect some BIG problems!

  ,--,             Chris StJohn, LIX, Ecole Polytechnique, 91128

 /    /_  __' _    Palaiseau, Cedex, FRANCE. (+33) 1.69.33.45.93

(____/ (_/ (_/_) - actively seeking employment in the UK (ha! :) ---------------     email address change: cstjohn@nyx.cs.du.edu

PS: On my board there's a big 16MHz crystal hooked up to a NAND gate chip... why don't you try following where the output of that clock goes and trapping it somewhere on the board instead of messing with the Tube? Knowing Acorn, there's probably a pin somewhere on

the board that lets you plug straight in to the system clock ;-)


Re: Tube connections (was RE: colour Graphics)6
Date: Wed, 14 Jul 1993 13:10:13 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: stjohn@poly.polytechnique.fr

Subject: Re: Tube connections (was RE: colour Graphics)

Date: Tue, 13 Jul 93 12:50:06 +0200

From: stjohn@poly.polytechnique.fr

>>So, this seems to indicate only the low 8 locations are required by TUBE

>>hardware. Does the splitter ensure splitter switching writes don't make it

>>to the second processor? (What I'm really asking is, if a write is make

>>to a second processor above those bottom 8 locations, does it ignore it,

>>or might it panic?)

>

> Pandora won't. I've disassembled all the importants parts of it so

> I can guarantee that in general it won't panic. If you want to make

> extra sure, see the new AUG which details the Tube I/O and protocol.

Hmmm, but does the tube ULA mask out the illegal address?

> Be careful with NMI because Pandora at least uses the NMI as a

> sort of software DMA. After a disk I/O the beeb sends NMIs to the

> 32016 with data in the Tube ULA. This is how data is transfered

> transparently into the second processor. If you start fiddling with

> them, then expect some BIG problems!

Hmmm, is that a function across the tube? I have a feeling that is a function on the 2nd processors onboard tube ULA, not involving the NMI line on the tube connector....

> PS: On my board there's a big 16MHz crystal hooked up to a NAND

> gate chip... why don't you try following where the output of that

> clock goes and trapping it somewhere on the board instead of messing

> with the Tube? Knowing Acorn, there's probably a pin somewhere on

> the board that lets you plug straight in to the system clock ;-)

Now you've hurt my feelings! :-)

In fact, the best line to take would be the character clock straight off the 6845. What I'm trying to achieve here is a solution that doesn't require nasty connections inside the machine. I figured a plug-in solution was far more preferable....?


Re: Tube connections (was RE: colour Graphics)7
Date: Wed, 14 Jul 93 10:17:23 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To:  bbc-list@ohm.york.ac.uk

Subject: Re: Tube connections (was RE: colour Graphics)7

>Hmmm, but does the tube ULA mask out the illegal address?

possibly possibly not, but your best bet is to mask out the extra addresses in  your board, then attach the 2P to that. This will probably be necessary anyway,  as the tube is sensitive about what loads it can drive. If you add a buffer then you an exted the length of the cable, and I would sugguest passing through  NTUBE only for addresses in the range E0->EF, keeping F0->FF for yourself.

>But what about the other direction? Are the tube registers polled on the IO

>processor? I always assumed that they were tested on IRQ, in fact, it

>seems strange that Tube IRQ is an output, as the IRQ line is used for all

>the hardware that the 2nd P shouldn't care about. Are you sure about that??

There are no references to IRQ's or NMI's on the circuit diagram that I have.  Though its possible that they've been missed out (unlikely), it makes sense to  have NO interupt connections accross the systems.

Any interupts on the 2P should be generated by hardware on that machine -  otherwise what is it going to service! No doubt certain writes to the tube chip  DO generate interupts, but these are strictly internal.

The Host can operate via polling, as its not actually DOing anything else. The  timing isn't critical (for most comms), as the tube chip ios designed to allow  the systems to run asyncchronously. Using interupts would lock the two machines  together, and drastically reduce performance (self timed systems are currently  hot research, as they're difficult to build, but invariably run much faster, as  each part runs flat ot whenever it can).

Ian


Re: Tube connections (was RE: colour Graphics)8
Date: Thu, 15 Jul 1993 08:52:44 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Tube connections (was RE: colour Graphics)

Date: Wed, 14 Jul 93 10:17:23 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

>>Hmmm, but does the tube ULA mask out the illegal address?

>

> possibly possibly not, but your best bet is to mask out the extra addresses in

> your board, then attach the 2P to that. This will probably be necessary anyway,

> as the tube is sensitive about what loads it can drive. If you add a buffer

> then you an exted the length of the cable, and I would sugguest passing through

> NTUBE only for addresses in the range E0->EF, keeping F0->FF for yourself.

Sounds sensible.... I'm sort of keen for software to be able to auto-detect the extra hardware though, and if the tube misbehaves when writing the "auto-detect" addresses, that'll cause problems...

>>But what about the other direction? Are the tube registers polled on the IO

>>processor? I always assumed that they were tested on IRQ, in fact, it

>>seems strange that Tube IRQ is an output, as the IRQ line is used for all

>>the hardware that the 2nd P shouldn't care about. Are you sure about that??

>

> There are no references to IRQ's or NMI's on the circuit diagram that I have.

> Though its possible that they've been missed out (unlikely), it makes sense to

> have NO interupt connections accross the systems.

>

> Any interupts on the 2P should be generated by hardware on that machine -

> otherwise what is it going to service! No doubt certain writes to the tube chip

> DO generate interupts, but these are strictly internal.

Another assumption I always made was that there was no special tube hardware on the BBC side of the tube, so any interrupts generated by Beebward communications would be generated on the 2P on-board ULA, and sent across the tube connector....

Is this right or wrong?

> The Host can operate via polling, as its not actually DOing anything else. The

> timing isn't critical (for most comms), as the tube chip ios designed to allow

> the systems to run asyncchronously. Using interupts would lock the two machines

> together, and drastically reduce performance

Well, the connection can still be buffered, but an interrupt to say that the buffer was indeed pending processing would be infinitely useful....

Dave.


Tube for video enhancement...
Date: Sun, 18 Jul 1993 22:05:01 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Tube for video enhancement...

... is out.

The BBC system clock runs at 2MHz, but drops to 1MHz whenever an access to the memory mapped IO is made. Pity I conveniently forgot this!

Can you people with circuit diagrams of the model B and master tell me a nice point I could take a clock from inside the machine? I guess the nicest would

be an 8MHz clock in the model B, then master users could run a line from the cartridge 8MHz pin to save mucking around inside....

Anyone?


Unix
From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

Date: Wed, 21 Jul 1993 20:00:59 +1200

To: bbc-list@ohm.york.ac.uk

Subject: Unix

By the way, I've set up my Unix account to interact with tequilacomm quite nicely. At startup a program is run to detect tequilacomm, and set an environment variable to the result. This automatically triggers setting the screen height to 32 lines, rather than thinking only the puny 24 lines is avaliable.

I also have emacs set up to recognise the ctrl/shift-left/right cursor keypresses, and also select "remote edit" mode, and clear the same when emacs is suspended or killed. (Remote edit mode is new, and not in a currently released version of tequilacomm. It changes the shift up/down sequence from entering scrollback to sending the "page up/down" codes.

Emacs nicely selects this mode when run, and whenever it is exited switches back to scrollback, as I have it configured).

Are any people using tequilacomm in a unix environment, and would like this work made avaliable?

Dave.


Synchronous modem emulation
From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

Date: Mon, 2 Aug 1993 13:07:38 +1200

To: bbc-list@ohm.york.ac.uk

Subject: Synchronous modem emulation

I've just got the chip I needed to make the BBC emulate MNP4 and V.42!

[Only took a couple of months! :-( ]

MNP2 is already going over the RS423 port, so the software side is basically done. What I may do is just design the hardware, and get MNP4 going. I still don't have all the info on V.42bis, and I have NO info on MNP5, but MNP4 is definately worth having (More speed PLUS no line noise!). Also, a lot of modems no longer support MNP2, so relying on the RS423 by itself dosen't work too well.

This is a significantly cheaper way to go than buying a new modem! (In fact, it's better than most MNP emulations on top of a 2400bps modem, my emulation always has to step DOWN to the level of the modem it's communicating with!)

Once it's going, I'll release another version of Tequilacomm, and info on how to build the hardware side... (Dual serial ports, Z8530 based, hung off the 1MHz bus), and those who are still using their beebs as a terminal can laugh at the poor IBM users forking out their money for MNP modems! :-)

It may be a while after than that I get V.42bis going (LAPM error correction will be a breeze, but without the compression it'll be relatively useless, just use MNP4).

Hope this is useful to people. If you still want to use another machine as a terminal but would like your modem to be MNP/V.42 capable, I may be willing to throw something together so the BBC sits between your modem and other machine converting the signal.....

Dave.


Micron EPROM Programmer info sought
Date: Fri, 13 Aug 1993 00:37:32 +0100 (BST)

From: Jeremy Prior <jez@praxis.co.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Micron EPROM Programmer info sought

All,

    Last weekend, I picked up an EPROM Programmer exceedingly cheaply.  The problem is that I don't have any documentation or software with it.

Details:

    It is an H.C.R Electronics MICRON EPROM PROGRAMMER, with a 28pin ZIF socket, a switch marked PROG/READ and an LED marked ENABLE.  It has two

banks of 6 DIP switches labelled `A' and `B' (I've no idea what these are for, but they look well used)!  It also has a standard 20way ribbon cable with user-port connector at the end.

So, my question is:  What do I need to get this working?  Can anyone point me at (in this order)

  - Software to drive this thing;

  - A technical spec that I could use to write some m/c to drive it;

  - The phone number of H.C.R Electronics;

  - Any other info that is relevent.

Thanks in advance,

jez

--

Jeremy Prior (jez)                               Telephone:   +44 225 444700 Praxis Systems plc, 20 Manvers Street,                 Fax:   +44 225 465205 Bath, AVON, BA1 1PX, UK                              Email: jez@praxis.co.uk


PC DFS
Date: Mon, 16 Aug 93 20:58:59 +0100 (BST)

From: "Roger Peppe" <rog@ohm.york.ac.uk>

To: ian@ohm.york.ac.uk

Subject: PC DFS

is this for you ?

i don't remember giving anyone a bbc dos fs...

  rog.

Begin forwarded message:

From: jb-b@minster.york.ac.uk

Date: Sat, 14 Aug 93 14:36:03

To: rog@ohm.york.ac.uk

Message-ID: <swordfish.745340414@minster.york.ac.uk>

Subject: PC DFS

Content-Length: 263

Dear Roger,

Thnak you for the reply. I have found the file:

   /pub/BBC/Submissions/dosfs.tar.Z.

Is this the correct file? If it is, could you please tell me how to remove the .tar extension, and what to do with it once it is on a BBC.

Many thanks,

Joe Boon


Change of email address
Date: Fri, 3 Sep 93 15:13:59 MET DST

From: Gerben Vos <gpvos@cs.vu.nl>

To: gpvos@cs.vu.nl

Subject: Change of email address

Hello,

due to my job as a student assistant this year, my account name and email address are about to change. The new address is

gerben@cs.vu.nl

Within a few days you can send mail to this address; hopefully (for them) the system administration will set up a mail alias for my old address.

Gerben Vos <gpvos^H^H^H^H^Hgerben@cs.vu.nl>


Newbie on the list ;-)
Date: Mon, 20 Sep 93 10:33:09 EDT

From: Bonfield "James./Staden" <jkb@mrc-lmb.cam.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Newbie on the list ;-)

Hello,

As my first post to the list I think I'll describe my system and my interests. I currently have a BBC B issue 7, twin 40/80 track drives, solidisk 128K sideways ram board (does somewhat iffy things to the user port :-() and SideAID 128 (rom utility to go with the above board).

I've been writing, together with Stephen Youell, what we have called the Hackers ROM. Basically it's lots of useful utlities all bunged into a single ROM. Currently written things include disk editor (can handle lots of nastily formatted disks), scrollable memory editor and 65C02 disassembler, printer buffer, lots of {search, copy, fill, swap, read, write} utils for sideways ram or disk. I shouldn't really be explaining too much about it now as no doubt we won't ever get the thing finished! We 'hope' to get something stable by the end of the year. (It's taken 4-5 years so far as it's very much a spare time project).

Other interests involve protection - the best part of any game has got to be the wonderful protection ;-) (I learnt most of my 6502 from deprotecting Exile.) In case you're frowning on this - I'm not really a pirate (who wants to copy and play the games anyway? only a few are really worth it) - I just enjoy the challenge *grin*. Currently, there is only one game that's ever beaten me; Red Arrows. (I've got it all loaded into memory and can save it, I just haven't managed to save the configuration of the 6522 etc.)

I've got a DES (Data Encryption Standard) encryption program that I should be able to get onto UNIX and hence on the ftp site. If people want such a beast then it'll be interesting to know. It supports both ECB and CBC cipher methods.

Anyway, I shouldn't waste too much band width with idle chatter. I look forward to joining in the list and it's discussions.

Cheerio for now,

James 'Rince' Bonfield


Re: Newbie on the list ;-)
Date: Wed, 22 Sep 93 10:57:14 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Newbie on the list ;-)

>	I've got a DES (Data Encryption Standard) encryption program that I

>should be able to get onto UNIX and hence on the ftp site. If people want such

>a beast then it'll be interesting to know. It supports both ECB and CBC cipher

>methods.

That sounds pretty cool! Love to see it...

Things have been pretty quite over the summer break, but prehaps stuff will  pick up with the new college year. There's also been some problems with the  machines here for the last week (there may be problems for the next few days  until everything is restored from backup).

What happened to a couple of the hardware projects?

Dave Sainty: Did you ever do any more work on your graphics board?

Richard York: Real time clock?

I'd really like to get hold of some of these.

Did anyone pick the C compiler from shiraz? Any feedback on that would be  appreciated - I haven't had time to do any work on it for ages but its still  something I'd like to get working better.

Ian


Re: Newbie on the list ;-)1
From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

Date: Thu, 23 Sep 1993 18:59:37 +1200

To: bbc-list@ohm.york.ac.uk

Subject: Re: Newbie on the list ;-)

Date: Wed, 22 Sep 93 10:57:14 +0100 (BST)

From: I Stephenson <ian@ohm.york.ac.uk>

> What happened to a couple of the hardware projects?

> Dave Sainty: Did you ever do any more work on your graphics board?

> Richard York: Real time clock?

> I'd really like to get hold of some of these.

Ever since I got the essential component for my V.42 emulation, that was my priority. But even that is on hold, as I have way too much varsity work to get done. On hold, but not forgotten....


Re: Newbie on the list ;-)2
Date: Thu, 23 Sep 93 12:23:29 EDT

From: Bonfield "James./Staden" <jkb@mrc-lmb.cam.ac.uk>

To: ian@ohm.york.ac.uk (I Stephenson)

Subject: Re: Newbie on the list ;-)

Hello,

>>	I've got a DES (Data Encryption Standard) encryption program that I

>>should be able to get onto UNIX and hence on the ftp site. If people want such

>>a beast then it'll be interesting to know. It supports both ECB and CBC cipher

>>methods.

>

>That sounds pretty cool! Love to see it...

I'll have to dig it up. It's currently in several parts - a basic program to assemble the code and save to disk, and a basic frontend to drive the machine code program. It creates a 'whatever.E' and you should remember to blank 'whatever' first (for small files simply a clear memory and *SAVE over the top should suffice) before removing.

There was another DES program published in the Micro User just as I was finishing mine. They appeared to encrypt to different strings which is worrysome. They both decrypted correctly, so quite what is different I'm uncertain. I've never got around to testing mine to see if it does infact encrypt correctly. My implementation was (on something like a 20K file) about 7 times faster than the micro user one. Mainly due to the fact that the MU one for some absurd reason kept recalculating the 16 keys for each 8 byte block which needs only be done once.

I can get it onto a UNIX system via a friend. Is that an acceptable medium for you?

James


Forward
Date: Thu, 23 Sep 93 10:24:34 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Forward

This got sent to bbc-list-request.

(Steve - I've added you to the list, send future stuff to bbc-list)

Still its good to be picking up some new people.

Begin forwarded message:

From: Stephen Youell <syouell@dcs.warwick.ac.uk>

Subject: Beebs and bits

To: bbc-list-request@ohm.york.ac.uk

Date: Wed, 22 Sep 1993 17:45:26 +0100 (BST)

Hello,

I believe some of you have already met my hacker-in-arms James Bonfield. Hopefully our four-year-long conquest to get our rom finished is coming to a close (?). It's beginning to get more organised, there should be a working (but not quite complete) version out in a couple of months (landed you in it there James).

As a matter of interest how are other people getting their software onto the net. I am currently using an RS232 cable between my Beeb and a PC running linux and then copy off onto a disc and stuff it into a Sun IPX and download it from there. Kermit is being used for the file transfer between the PC and the Beeb.

Has anyone seen this new Beeb magazine,erm Byte Back I think its called. I have been in contact with the Editor and his philiosophy for it is more on the lines of support for people who have dug up their beeb after a few years or people who have got them at a car boot sale (sacrilege), new users basically.

I suggested that there are many hardened beeb hackers in the world but it doesn't seem to have made any impression. Shame really because somewhere to trade juicy beeb info, (if some of us have anything left to learn - I'm a bit lacking on the ins and outs of the tube and second processors - anyone got a 32016 second prcessor going cheap?), that would be a valuable resource. comp.beeb.wizards? :-).

I have got the HDFS by Angus Duggan and the 65C02 Assembler and Kermit by Alan Phillips and all are impressive so there's some talent out there. To add to the list, hardware is my game, my beeb looks like it's had surgery with a soldering iron, 64k Eprom/Ram emulators, 128k ram expansion board (if anyone has pcb etching facilities I have the artwork for it, it costs about 30 quid to build) I have a patch board with a rather lame 6502 driving an LCD display (will be a bike computer eventually). What other knowledge is out there?

If anyone can get me a copy of the Advanced Basic Rom User Guide then give me a shout. I think it went out of print about 3-4 years ago so Adder Publishing tell me - and they should know.

Steve Youell

--

- syouell.{sbd-e,wgc-e}@rx.xerox.com    __-----__    __

- Stephen_Youell.wgc-e@rx.xerox.com  _-/__|__\___\__/ .\   Billy the tortoise

- csujg@csv.warwick.ac.uk          _/__|__|__|___|--___/    - 48 years and

- syouell@dcs.warwick.ac.uk        // ----------- \\           counting


Re: Beebs and bits
Date: Thu, 23 Sep 93 10:46:55 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Beebs and bits

I'm having a bit of a BBC week, so I think I'lkl throw some more stuff in...

>As a matter of interest how are other people getting their software onto the net?

I'm kinda lucky - I've got a serial line from a bbc (about 18" from my right  shoulder) straight into shiraz (a NeXT, 12" in front of me), so I can transfer  stuff around VERY easily. We used to have a lab full of BBC's but that was  replaced, so the computers were put into store. I asked the techie's nice, and  they dug me out a system which I keep permanently connected (this is esential  for developing cross compilers!). If anyone isn't sufficiently connected to get  transfer stuff, then mail me, and we can sort out some floppies.

>if some of us have anything left to learn - I'm a bit

>lacking on the ins and outs of the tube and second processors

>anyone got a 32016 second prcessor going cheap?

Last I heard "Bruce 'Loodvrij' Keeler" <csc228@central1.lancaster.ac.uk>

had a Cambridge workstation he wanted to part with (this was about a year ago -  If he still has it then he should virtually give it to you).

Tube doc's are pretty thin on the ground - largely because Acorn screwed up the  marketing of the Tube, so that no-one had them  (until recently when pople like  us started picking them up cheap). Acorn could have released a 68000 based  system for say 150 pounds, just as the ST/Amiga's were taking off, and they  would have sold millions. Instead they over priced them, keeping them out of the mass apeal, and the rest is history :-(.

Anyone looked seriously at BUILDING a second processor? Can you get the ULA?  Does anyone have a definative idea of the tube protocol?

>If anyone can get me a copy of the Advanced Basic Rom User Guide then give me

a shout.

Is that the one to go with he Advanced User Guide? I've got that one, but never  though much of it. There was another that was supposed to be better, but I can't remember the exact titles.

On that subject (ie books), does anyone have a spare "Advanced User Guide"? I  left mine at my parents, and my brother leant it to a friend! I've been trying  to get it back for ages, but its at least 100 miles away, so is a bit hard  applying preasure.

Does anyone want a copy of:

Boris Allan: funcitonal forth on the BBC micro?

I've aquired a spare copy, so if anyone wants it, they're welcome to it.

Ian


Re: Beebs and bits1
Date: Thu, 23 Sep 1993 23:48:52 +1200

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Beebs and bits

Date: Thu, 23 Sep 93 10:46:55 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

Comments: BBC Mailing List

> Anyone looked seriously at BUILDING a second processor? Can you get

> the ULA?  Does anyone have a definative idea of the tube protocol?

I think the ULA is different for each type of processor. The TUBE bus is very simple, and only runs at 2MHz. The tricky bit would be the buffering of the interface, but lets face it, that could be done in software with most modern CPU's. :-)

The protocol is reasonably simple I think, to allow it to work on any processor type, with extra bits for special purpose processors, like the 8018 PC emulation, dealt with by an extra layer on top of the tube protocol. The New Advanced user guide goes into it in enough detail I think....

You could probably get a 2nd processor up and running with a register file and some interrupt control hardware, or maybe just a bunch of 8 bit latches.

Dave.


Second Processors
Date: Thu, 23 Sep 1993 17:51 GMT

From: John Whistler <JOHN_W%VULCAN@mentec.ie>

To: bbc-list@ohm.york.ac.uk

Subject: Second Processors

"I Stephenson" <ian@ohm.york.ac.uk> writes:

> Anyone looked seriously at BUILDING a second processor? Can you get

> the ULA?  Does anyone have a definative idea of the tube protocol?

Several years ago, ETI had an article on building a 6502 2nd processor for the Electron; I believe it also worked on the beeb. There was also a couple of articles in Electronics & Computing Monthly on using the Dragon-64 as a 6809 2nd processor. I still have a copy of the E&CM articles, but I'm not sure if I kept the ETI one.

        John W.


Hardware projects & Emulators
Date: Fri, 24 Sep 1993 06:44:16 PDT

From: Stephen_Youell.wgc-e@rx.xerox.com

To: bbc-list@ohm.york.ac.uk

Subject: Hardware projects & Emulators

I have seen a graphics board and a real time clock mentioned in a couple of bits of mail. What do these actually do? - the clock is fairly obvious but I'd be interested in the graphics board. I tend not to venture into analogue electronics myself, if it's on and off (sort of - some of my little projects have managed to cut out my radio - don't you just love patchboard :-). Does anyone have any interesting little hardware projects or ideas that have finished, completed, still a twinkle in the inventors eye?

What I've always wanted to know is what the pinout of those ULA's.  Going off at a bit of a tangent , has anyone ever tried to write a beeb emulator with any success. I've seen an attempt at one which was a conversion from an Apple II emulator which wasn't much cop, what we (James B and myself) would like to do is to be able to run a beeb emulator under X-Windows, just importing raw 6502 binaries and watch them trundle away - Revs on X-Windows ;-) - dream on I think. Anyone want to try and emulate the sound chip (never mind the 6845).

Steve Youell


Re: Hardware projects & Emulators
Date: Mon, 27 Sep 93 10:57:53 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Hardware projects & Emulators

>Has anyone ever tried to write a beeb emulator with any

>success. I've seen an attempt at one which was a conversion from an Apple II

>emulator which wasn't much cop, what we (James B and myself) would like to do

>is to be able to run a beeb emulator under X-Windows, just importing raw 6502

>binaries and watch them trundle away - Revs on X-Windows ;-) - dream on I

>think. Anyone want to try and emulate the sound chip (never mind the 6845).

>

>	Steve Youell

That sounds like the one I wrote...

Yes it's limited, but it's written to be prety extensible (I did add some  graphcs capability, but it wasn't so effective, and needed NeXTStep, so I didn't release that version). However you can "just importing raw 6502 binaries and watch them trundle away", provided certain stuff is avoided. If  you're intersted in taking it further it's probably a ggod start.

To load in binaries you need to add a header, which specifies the load and  execution address.

There's a pseudo instruction which makes an OS trap. This has been inserted into the copy of the ROM, at the strategic entry points. This calls the function OS, which then switches to the appropriate routines. Filling out these  routines would allow you to get all legal stuff running (it would probably be a  good idea to reshuffle this to make it look like a co-processor).

To get the illegal stuff going you need to get into the read/write memory stuff. This is done by two funcitons which currently just block writes to ROM.  Memory mapping hardware would be pretty easy (apart from the actuall  impementation of a complex chip).

I converted the code into objective C. This makes it a little slower  (potentially - I never noticed it), but makes it much easier to manage. There's  a seperate Object to manage the screen, which you can just send vdu codes to.  This almost worked, but had some problems of staying in sync. There's also a  seperate memory object, keyboard, and other bits. I can release this if anyones  interested.

Ian


Re: Hardware projects & Emulators1
From: Bonfield "James./Staden" <jkb@mrc-lmb.cam.ac.uk>

Date: Mon, 27 Sep 93 14:02:39 EDT

To: ian@ohm.york.ac.uk (I Stephenson)

Subject: Re: Hardware projects & Emulators

Hello,

[...]

>I converted the code into objective C. This makes it a little slower

>(potentially - I never noticed it), but makes it much easier to manage. There's

>a seperate Object to manage the screen, which you can just send vdu codes to.

>This almost worked, but had some problems of staying in sync. There's also a

>seperate memory object, keyboard, and other bits. I can release this if anyones

>interested.

I'm certainly interested - more so in a C than Objective C version. (I do not know Objective C and I'm not sure how well gcc suports it yet either.) It does sound very similar to the style of system we were going to design. We were thinking of going the whole hog and trying to get everything to run under it ;-) Ambitious I know!

But first things first, a reasonable system that can support sideways ram banks etc for developing our ROM would be useful.

James


Free HD controllers
Date: Mon, 27 Sep 93 09:56:01 BST

From: Grimthorpe <stj@computer-science.manchester.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Free HD controllers

Ok, this is a once-in-a-lifetime offer.

For the mere cost of postage and packaging I can offer 2 Adaptec ST506 controller boards with winchester host adaptor cards.

Please reply if you are interested.

NB these will be distributed on a strictly highest need priority.

The reason for them being free? Thats how much I paid for all of my HD's. Due to my bodge of wiring, I thought that both of the adaptec cards were broken, but it turned out that they weren't damaged at all.

Adrian StJohn

PS I don't have any ADFS roms to go with these, but they shouldn't be too hard to get hold of.

PPS I found a ROM of Advanced 1770 DFS (Rather nice DFS variant) in a master compact a few weeks ago. Can anyone tell me how much I'd have to change to make it work on a B+? (I know the FD controller addresses have changed, and I've already patched that in, but it still wont work)

---------------------------------------------------------------------

 I couldn't care less about apathy


Beeb newsgroup
Date: Thu, 30 Sep 1993 02:31:25 PDT

From: Stephen_Youell.wgc-e@rx.xerox.com

To: bbc-list@ohm.york.ac.uk

Subject: Beeb newsgroup

Has anyone ever considered a beeb newsgroup before? Has anyone ever tried to set one up? It would certainly be an interesting read - think of the FAQ! I'm not sure how many beeb users there are out there, comp.sys.acorn seems a bit flooded with Archimedes stuff.

Any thought?

Steve Youell

PS - Watch out for the rom James Bonfield and I have written arriving soon. Fixed my verifyer last night (no ordinary verifyer). It works at the moment, we just have to make it presentable. It needs Alan Philips 65C02 Assembler, there will also be a MAKE utility supplied with it for sorting out the dependencies. It'll be a beta-test so I think I speak for James and myself by saying that we would like everyone to have a go at using it and hacking it to pieces to point any flaws (bugs even - what are those?). If there's anything that should be added. Not all the commands are implemented yet. It is our most stable release for 4 years so enjoy!


DES, RFS maker, UIM editor
Date: Tue, 28 Sep 93 12:03:04 EDT

From: Bonfield "James./Staden" <jkb@mrc-lmb.cam.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: DES, RFS maker, UIM editor

Hello,

I've got a few bits and pieces of software I've knocked up in the past that I thought I'd share with the list. If someone has a better home (ftp site) for them then that'd be nice.

Currently they reside on al.mrc-lmb.cam.ac.uk(131.111.84.16):/pub/beeb.

Let me know how you find them. The programs currently there are:

bdes

kdes

DES encryption package using CBC or ECB cipher methods. It does decrypt what it encrypts (useful that bit!), but I haven't yet checked to see whether it encrypts to the same as proper DES does. I trust it reasonably though. Remember that when removing the original unencrypted file you should blank it with *SAVE or something first.

uim-ed

Editor for UIM (naff game in my opinion) saved game position. It's amusing to cheat and finish it if only to see how bad the perspective is on the finish screen.

rfsmake

Makes ROMs suitable for the *ROM filesystem. Handy as a hacky way of converting tape games to disk ;)

James


NEED disc organizing software
Date: Fri, 01 Oct 93 10:54:09 +0400

From: ad@arm.misis.msk.su (Alex Petrov)

To: bbc-list@ohm.york.ac.uk

Subject: NEED disc organizing software

I am writing on behalf of  my friend who reads this list but is  unable  to  write  himself  (due  to  difficulties  with Englisn).

He has a Master and lots  of discs. He needs a program which can  help  him  to  eliminate  multiply  copyes of the  same program form different discs. Is there anything of that kind avialable as PD?

Thank you

Alex

--

 ad@arm.misis.msk.su (Alex Petrov)

 Russian ARM Support Group


introduction
Date: Thu, 7 Oct 93 11:32:47 BST

From: J Day <jeday@castle.edinburgh.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: introduction

Hello,

Just by way of introduction - I am a postgraduate student at the University of Edinburgh.  I use three BBC Master Systems to control experimental apparatus via the user port.  I am currently trying to build up a system which records events via an interface and writes datafiles to disc in real-time.  My ideal solution would be to obtain some Winchester Hard disc drives for the Masters so data collection would be a lot easier.  I would welcome any help on how to obtain such a device.  I have been told that it could be possible to network the machines and use an old BBC B as a fileserver to write to and from disc.

Could anyone help?

jeday@uk.ac.ed.castle


Re: introduction
Date: Fri, 8 Oct 1993 00:14:17 +1300

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>To: bbc-list@ohm.york.ac.uk

Subject: Re: introduction

From: J Day <jeday@castle.edinburgh.ac.uk>

Date: Thu, 7 Oct 93 11:32:47 BST

> Hello,

>

> Just by way of introduction - I am a postgraduate student at the

> University of Edinburgh.  I use three BBC Master Systems to control

> experimental apparatus via the user port.  I am currently trying to

> build up a system which records events via an interface and writes

> datafiles to disc in real-time.  My ideal solution would be to obtain

> some Winchester Hard disc drives for the Masters so data collection

> would be a lot easier.  I would welcome any help on how to obtain such a

> device.  I have been told that it could be possible to network the

> machines and use an old BBC B as a fileserver to write to and from disc.

>

> Could anyone help?

Can you be more specific on the sampling speed and volumes you're looking at here?


Re: introduction1
Date: Fri, 8 Oct 1993 02:54:48 +1300

From: David Andrew Sainty <David.Sainty@comp.vuw.ac.nz>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Introduction

From: J Day <jeday@castle.edinburgh.ac.uk>

Date: Thu, 7 Oct 93 14:01:06 BST

>> > University of Edinburgh.  I use three BBC Master Systems to control

>> > experimental apparatus via the user port.  I am currently trying to

>> > build up a system which records events via an interface and writes

>> > datafiles to disc in real-time.  My ideal solution would be to obtain

>> > some Winchester Hard disc drives for the Masters so data collection

>> > would be a lot easier.  I would welcome any help on how to obtain such a

>> > device.  I have been told that it could be possible to network the

>> > machines and use an old BBC B as a fileserver to write to and from disc.

>> >

>> > Could anyone help?

>>

>> Can you be more specific on the sampling speed and volumes you're

>> looking at here?

>>

> Yes.  I currently run three separate Master Systems which collect files

> about 150k per day.  Each file is built up quite slowly, but at maximal

> speed would need to write 2 lines of data per second.  If the three

> computers were linked to another to act as a fileserver then the disc on

> that machine would need to have three separate files open each with a

> capacity of 150k ish.

A master can store 640k (I think?) on one 80 track disc. It can certainly keep up with the data rate you require. Your easiest solution would be to drop two of the masters and just use one. This means slightly more complex hardware, but saves you networking, or having to use several disc drives, and leaves you with a couple of masters free to use Tequilacomm on. :-)

Only other problem is what the hardware is actually doing, because whilst the disc drive is saving data the speed you can look at the user port will be reduced. No problem if the rate you are talking about is reasonably consistant, but if you are talking about very high speed bursts of data you may have a problem.

Hmm, here's a way around that... Use two masters, one set up as above, but buffering the data and sending is at a slow but consistant rate throught the serial port to the other machine that then saves to disc. Linking two machines with the serial port is cheap, and with the server dealing with the disc drive, all the possibly high volume work (watching the user port and writing to the drive) are isolated to one machine each.

But I think you can do it all with one machine...


Chess stuff
Date: Thu, 14 Oct 93 14:49:30 +0100 (BST)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Chess stuff

With all the chess on TV, I decided to dig out my old copy of MicroPower chess and give it a go.

My feelings were somewhat mixed when after about four games I started to thrash  it quite regularly! Previously it ALWAYS beat me, so I've obviously got better  :-), but it does mean that my BBC isn't much of a challenge :-(.

I remember hearing very good things about "White Knight II" (OK its hardly state of the art, but I'm really not very good). Does anyone know where I could  get a copy ;-) ?

In the mean time I've been playing round writing a BBC ICS client! Once I've  drawn the icons I should have a mouse driven chess board, which I can then  interface to ICS/gnuchess or whatever via a serial line to a Unix. If this is of interest to anyone then I'll pass it on.

Ian

P.S. Chris - Are you recieving this, as I can't email you, but the list doesn't  bounce!


Re: Chess stuff
From: Philip Sainty <Philip.Sainty@comp.vuw.ac.nz>

Date: Fri, 15 Oct 1993 08:43:50 +1300

To: ian@ohm.york.ac.uk

Subject: Re: Chess stuff

Ian says:

> With all the chess on TV, I decided to dig out my old copy of MicroPower

> chess and give it a go.

> My feelings were somewhat mixed when after about four games I started to

> thrash it quite regularly! Previously it ALWAYS beat me, so I've obviously

> got better :-), but it does mean that my BBC isn't much of a challenge :-(.

> I remember hearing very good things about "White Knight II" (OK its hardly

> state of the art, but I'm really not very good). Does anyone know where I

> could get a copy ;-) ?

Well I'm afraid I can't help there, but I do know that the very best chess program for the beeb is undoubtedly "Colossus 4 Chess". I remember seeing some statistics from a tournament in which it had beaten each opponent (all other programs) in a sixteen game contest, and that only a couple had managed to win any games at all...

I'm sure it is the best, as it was written by the author of the "White Knight" chess games which would be the next best... (and which, incidentally, reached version 12 if I remember correctly)

I imagine it has a good range of difficulty levels if that sounds intimidating, and I believe it even has a 3D board should you wish it :) (Master, or possibly just expanded B, version only if I remember)

If you used to get "The Micro User" I think there is a review in the issue with a light blue cover showing a man sitting down holding a flare gun in his lap... something to do with airports perhaps... I think it's an '86 or '87 issue

If anyone knows how to get hold of it, I too would be most interested... :-)

> In the mean time I've been playing round writing a BBC ICS client! Once I've

> drawn the icons I should have a mouse driven chess board, which I can then

> interface to ICS/gnuchess or whatever via a serial line to a Unix. If this is > of interest to anyone then I'll pass it on.

Sounds cool... pity I don't have a mouse...

Philip


bbc winchester
Date: Thu, 14 Oct 93 17:55:33 BST

From: J Day <jeday@castle.edinburgh.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: bbc winchester

hello,

Would anyone know of where I could purchase Winchester hard disc drives for BBC Master Systems (either new or second-hand)?

I would appreciate any advice...

jeday@uk.ac.ed.castle


ICS Client Software
Date: Wed, 27 Oct 93 15:16:39 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: ICS Client Software

As I mentioned about a week ago I've been working on a BBC ICS (internet chess  server) client.

With a few reservations it is complete, and IT WORKS! It doesn't handle flow  control very well, so it occasionaly gets confused (its also a little slow in  displaying receiced text, but I've got a fix for that), but basically its about  as good as the NeXT ICS client, with the advantage it runs on nice 8-bit  hardware.

It needs an AMX mouse ROM to be present, but a mouse is not necessary (though

if you haven't got one I'd recomend using the super art ROM so you can enter  moves with a joystick/cursor keys rather than manually).

If anyone wants to try it out then mail me, and I'll distribute copies.

Ian


Screen Dump
Date: Tue, 16 Nov 93 14:35:23 +0000 (GMT)

From: "I Stephenson" <ian@ohm.york.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Screen Dump

Has anyone got a SMALL mode 1 (epson?) screen dump program?

The signal processing group here has developed some educational software for  schools that could really use a screen dump feature, but memory is a bit tight.

If anyone has a suitable program than can we have a copy?

(features are not such a big issue, just a basic dump).

Ian


E(PSON)DUMP.A01 UPLOAD
Date: 13:08:39 GLT THURSDAY 11/18/93

From: CACZ2201@GRTHEUN1.EARN

To: BBC-LIST <BBC-LIST@ohm.york.ac.uk>

Subject: E(PSON)DUMP.A01 UPLOAD

I have uploaded to Shiraz.ohm.york.ac.uk /pub/BBC/Submissions epdump.a01 : BBC graphic screen dump for Epson-compatible printers

Loads and executes at &A01. Save is as EPDUMP A01 A01

Can be run as *EPDUMP or (if loaded) CALL &A01


EPSON DUMP
Date: 12:20:35 GLT THURSDAY 11/18/93

From: CACZ2201@GRTHEUN1.EARN

To: BBC-LIST <BBC-LIST@ohm.york.ac.uk>

Subject: EPSON DUMP

Ian asked about a small Epson dump. I have one, but don't know how to send it to you. It is 182 bytes long and runs at &A01. If you want the code, send me mail at CACZ2201@ossa.ccf.auth.gr

o you


Bad disk drive
Date: Wed, 17 Nov 1993 08:47:56 -0500

From: "D'Arcy J.M. Cain" <darcy@druid.com>

To: bbc-list@ohm.york.ac.uk (BBC Mailing list)

Subject: Bad disk drive

My niece (6 years old) has a BBC which she loves but the disk drive doesn't work.  I am going to look at it to see if I can fix it.  Does anyone have any information or suggestions?  In particular can I just replace this with a single sided PC drive?  Double sided?  Can I expect the BBC drive to work on my PC as a test?  Any help really appreciated.

Thanks.

--

D'Arcy J.M. Cain (darcy@druid.com)  |

D'Arcy Cain Consulting              |   There's no government

Toronto, Ontario, Canada            |   like no government!

+1 416 424 2871  (DoD#0082) (eNTP)  |


Re: Bad disk drive
Date: Wed, 17 Nov 93 18:18:02 GMT

From: Grimthorpe <stj@cs.man.ac.uk>

To: bbc-list@ohm.york.ac.uk

Subject: Re: Bad disk drive

> From bbc-list-request@ohm.york.ac.uk Wed Nov 17 18:11:20 1993

> Return-Path: <bbc-list-request@ohm.york.ac.uk>

> Sender: <bbc-list-request@ohm.york.ac.uk>

> My niece (6 years old) has a BBC which she loves but the disk drive

> doesn't work.  I am going to look at it to see if I can fix it.  Does

> anyone have any information or suggestions?  In particular can I

> just replace this with a single sided PC drive?  Double sided?  Can

> I expect the BBC drive to work on my PC as a test?  Any help really

> appreciated.

>

> Thanks.

You can replace the drive with any shugart-standard one (nearly all drives) that ISN'T high density.

Both of my drives have been scrounged out of PC's, and work perfectly.

You may as well use a double sided drive, as this will work fine.

One problem you may find is that the drive light wont come on when it is being used. I assume this is due to the current that some drive lights require.

This has no effect on the operation of the drive, it just gets a bit worrying.

As for testing the BBC drive on a PC, this should be fine.

Adrian StJohn ---------------------------------------------------------------------

 Keep London tidy - Eat a pigeon a day


PERSONAL INFO (FIRST POSTING TO THE LIST)
Date: 11:18:25 GLT THURSDAY 11/18/93

From: CACZ2201@GRTHEUN1.EARN

To: BBC-LIST@ohm.york.ac.uk

Subject: PERSONAL INFO (FIRST POSTING TO THE LIST)

Hello to all BBC-users at York!

  My name is Dimitris Evangelinos and I am a Ph.D. student in the Physics Depart

 Since 1989 or so we are running here an Econet consisting of four Master128 mic

 We have developed and use until now two applications for the BBC, used in two f

  1. A projectile-motion program, simulating the lab procedures one would undert

  2. An on-line mechanics measurements program, that records, displays and manip

 Further details about the programs are available.

 As for the hardware, we mainly use DFS, ADFS, NFS, no hard disk. Also, various

 Currently in Greece the Acorn machines are not very well supported, if at all.

 My personal interests are in the use of Microcomputers in Physics Education and

 Since last year I am constantly scanning the networks for BBC software, without

 I think this is enough information for this first posting. Further info/queries

CACZ2201@GRTHEUN1.BITNET  (BITNET)

cacz2201@ossa.ccf.auth.gr (Internet)

Are there any bbc-list@ohm.york.ac.uk archives? If so, please help me accessing

The best of luck, Dimitris Evangelinos.


disks for BBC
Date: Fri, 19 Nov 1993 18:46:53 -0500

From: "D'Arcy J.M. Cain" <darcy@druid.com>

To: bbc-list@ohm.york.ac.uk (BBC Mailing list)

Subject: disks for BBC

Well I have managed to get my niec running for another disk drive but all of the disks (and I'm not even sure she has all she's supposed to) seem to be damaged except the LOGO disk.  I can't even format a new disk because I can't read the utilities disk.

Does anyone have any suggestions for getting software for her, in particular a replacement utilities disk?  Can I use Unix dd(1) or some DOS program to create the disk?  Many thanks for your help.

--

D'Arcy J.M. Cain (darcy@druid.com)  |

D'Arcy Cain Consulting              |   There's no government Toronto, Ontario, Canada            |   like no government!

+1 416 424 2871  (DoD#0082) (eNTP)  |


BBC EMULATOR
Date: 16:58:37 GLT THURSDAY 12/02/93

From: CACZ2201@GRTHEUN1.EARN

To: BBC-LIST <BBC-LIST@ohm.york.ac.uk>

Subject: BBC EMULATOR

I want to experiment with the BBC emulator found in SHIRAZ. I understand this is a unix version, that should be portable to PCs. Did anybody from the list have any experience in compiling the code for the PC?

I suspect the system here kills the mail from the bbc-list, so please answer to: mits@skiathos.physics.auth.gr

By the way, are there any archives of the list, and if so, how are they accessable?

Thanks in advance, Dimitris