Any mouse-driven GUI's for the BBC B?

[Commie_User]

If not, then what the dickens is the BBC mouse for?

On the Commie, I have GEOS, graphics and music programs, including the MSSIAH for my mice. (Talking of which, someone should make that for the BBC as well.)

[Pernod]

There's a range of art and desktop publishing packages that have mouse driven GUI. See here.

[Commie_User]

Whoa. I found some Commodore 64 mice and showcased them but I had no idea the AMX set could run on even the B. How DID they make 32K stretch?

http://www.remix64.com/board/viewtopic.php?t=8406


Could my Commodore 64 AMX be easily converted for the BBC? User Bryce has kindly made me a digital joystick adapter. Maybe I could ask him to look into this.

[Pernod]

How DID they make 32K stretch?

They didn't, the mouse handler and GUI were supplied in a 16K ROM, and for Stop-Press/Pagemaker another additional 32K ROM was required.

[Commie_User]

Again, whoa!

With all these ROMS needed for this and that, I gather base unit BBC Micros were oddly depleted. I know on the C64, utility cartridges were the ROMs for applications but even the Commodore 64 could run a mouse without a new chip. Same for a disk drive and who knows what else. Printer?

[sydney]

Again, whoa!

With all these ROMS needed for this and that, I gather base unit BBC Micros were oddly depleted. I know on the C64, utility cartridges were the ROMs for applications but even the Commodore 64 could run a mouse without a new chip. Same for a disk drive and who knows what else. Printer?

People using the beeb for serious appications will have bought a rom board like the Sidewise or WE 12 rom boards which let you add 12 roms + 16k of sideways ram.
The beeb also doesn't need a rom to use a mouse as long as the software was written to use a mouse, see mdfs for a BASIC mouse library. The ROM simply makes the mouse available to any software that wants to use it. Software that used a mouse on the C64 didn't need a ROM because the code to operate a mouse was included it those programs that needed it.

[Commie_User]

Was there much code needed to run a mouse? I knew the Commodore needed little. I think its 'big' RAM helped absorb the need for hefty control sets but I also realise that the BBC was way more expansive when equipped to perform the really specialist tasks.

The BBC has analogue and digital control ports, exclusive of each other. The Commodore 64, I've been told, has mixed type ports for its joysticks and mice. But the Beeb must have been able to do way more with the dedicated analogue socket at its disposal.

[DigitalDunc]

Commie User! Mice aren't difficult to drive on most 8-bit machines, but differing implementations were developed across the many platforms available. Whilst the C64 had sprites that were very helpful for providing a mouse pointer and which the beeb does not have (incurring a processor overhead), the 0.97MHz clock speed and C64 joystick port that the 1531 mouse plugged into wasn't helping things at all. On the early PC's there were even ANSI based GUI's proving you don't even need a bitmapped display. The key things that seem to required for a GUI and mouse is programming effort and memory, ROM being perfectly good because it frees RAM.

[sydney]

Was there much code needed to run a mouse? I knew the Commodore needed little. I think its 'big' RAM helped absorb the need for hefty control sets but I also realise that the BBC was way more expansive when equipped to perform the really specialist tasks.

I don't know for sure but I'd imagine it's simply a case of reading a value from the user port and replotting the pointer in the corresponding place. So just a few lines of code, probably.

The BBC has analogue and digital control ports, exclusive of each other. The Commodore 64, I've been told, has mixed type ports for its joysticks and mice. But the Beeb must have been able to do way more with the dedicated analogue socket at its disposal.

The mouse on a beeb plugs into the digital user port and not the analogue port. On the C64 it uses the joystick port but it seems there are 2 different modes. Have a look at the C64 wiki mouse page here: https://www.c64-wiki.com/index.php/Mouse
There isn't much C64 mouse compatible software either by the look of it:

Applications

Contiki Operating system
GEOS User interface
GoDot Picture edition program
Final Cartridge 3
Pagefox picture and word processing
Prophet64 music software

Games

Advanced Space Battle
Arkanoid
Arkanoid: Revenge of Doh
Brickout
Centauri Alliance
Heuristic Chomp
Landmine
Lemmings
Lords of Doom
Maniac Mansion (Mercury Version)
Maniac Mansion (GOLD Version)
Minesweeper (CP-Verlag)
Operation Wolf (US-Version)
Space Lords
The 15-Puzzle
The Faery Tale Adventure
The House
The Ultimate Wormgame

[jgharston]

Was there much code needed to run a mouse? I knew the Commodore needed little

No. Just an interupt service routine that is triggered on the mouse moving. The ISR checks which direction the mouse has moved and increments/decrements the X or Y position. Application software then just reads that X/Y position and does whatever it wants with it. The disk-based *MOUSE command linked to earlier is about 400 bytes, that includes the setup code and an interface to ADVAL(7) and ADVAL(8) to read the mouse position.

[MartinB]

We even got mice all fettled up on the humble Elk......

[ThomasHarte]

Again, whoa!

With all these ROMS needed for this and that, I gather base unit BBC Micros were oddly depleted. I know on the C64, utility cartridges were the ROMs for applications but even the Commodore 64 could run a mouse without a new chip. Same for a disk drive and who knows what else. Printer?

Everybody's going to leave this unchallenged?

Amongst the extra chips inside the Commodore 1541 disk drive: 4kb ROM, 2kb RAM, two 6522 VIAs, and a whole additional 6502. Which is clocked at a full 1Mhz. So when connected to a PAL C64, the disk drive has a faster processor than the computer does.

... and without third-party intervention it still loads more slowly than some tape titles.

Moral: it is not always appropriate to use number of chips or even absurd over-complexity as a measure of success.

[Commie_User]

I'd say it was a little different in the C64's case because the machine was able to open the disk drive channel and communicate unimpeded, regardless what gadgetry the 1541 had inside - or any subsequent storage system imitating the protocol. You can't just take that plug-and-play for granted with every stock BBC. Also, the 1541 was a whole additional computer system, freeing up the Commodore for new tasks once complex drive routines were commanded. Existing protocols could be overridden, as the BBC couldn't do to my knowledge.

And it wasn't the 1541 drive's fault for being so slow. The 64 was so rushed through development that the team had no time to iron the bugs from the transferred fast disk system they had. Subsequent software and cartridge products (including games or demos with drivers inbuilt) mostly cured this, making the 1541 faster than the BBC system.

[steve3000]

According to the user manual, the Integra-b ROM/RAM expansion card for the BBC B came with a mouse driver and GUI on disc, called "Integra Windows", which ran in 640x256 resolution MODE 0 and contained some example desktop programmes on disc, along with details of desktop programming APIs.

Unfortunately this disc was missing from my Integra-b card, and I've not been able to find a copy online - so I can't comment on how good it is/was.

...But if anyone does have this disc, or just a copy of the disc-loadable GUI (from my searches, the file was possibly a sideways RAM image, titled "Windows"), please let me know

[Commie_User]

There isn't much C64 mouse compatible software either by the look of it..

Well, not with that attitude! Certain types of mice had few or no games especially for them, though NEOS mice had a longer list of compatible titles than that.

But taking the gold are the 'joystick' mice, which are usable with virtually EVERY game! As-per the Atari Trakball. Some games are suddenly smooth and free with them, while others are more awkward. But a better list here would be to ask which games WOULDN'T control under them.

Pity there's nothing I know for the BBC to do that.

[flibble]

I found this picture of AMX Desk from an advert, did it look this good in real life? (proportionally spaced font?)

[sydney]

But taking the gold are the 'joystick' mice, which are usable with virtually EVERY game! As-per the Atari Trakball. Some games are suddenly smooth and free with them, while others are more awkward. But a better list here would be to ask which games WOULDN'T control under them.

That interesting. I was an avid C64 gamer back in the day so I'm wondering which games in particular are improved by using a mouse as a controller. I can imaging 'joystick waggling' games like Combat School or Run the gaulntlet would benefit and maybe some shooters. Do you know of any?

[Commie_User]

I can't really remember much. Maybe Arnie with the trackball. Certainly Spitting Image - with the trackball, a cumbersome beat 'em up is silky smooth. And the Arnie-style game on the 4 Most Combat tape is good, though I hate rolling the ball like crazy. I remember the mouse being way more precise for that game where you catch the bombs in the bucket.

[sydney]

Not a great list there mate! I'd have thought Arnie would be more difficult to play with a mouse. Something like Delta or Armalyte I can see being a much better experience as the screen scrolls constantly and all you'd be doing in moving your ship arournd the screen. I may see if I can log back into my old account over at lemon64 and ask about it over there.
Has anyone ever tried hooking a mouse up to the analogue port of the beeb to use instead of a joystick? Is it even possible? I think I can see my next hardware project taking shape

EDIT:
There is a quite recent thread on lemon about this very subject! http://www.lemon64.com/forum/viewtopic.php?t=61515
He's focussing on the 1351 analogue mouse and seems less than impressed with the joystick style 1350 mouse.

[Commie_User]

Has anyone ever tried hooking a mouse up to the analogue port of the beeb to use instead of a joystick? Is it even possible?

Well Bryce says yes because I asked into having him make me more adapters. But because the analogue techiness requires a whole fresh circuit board to the digital adapter, apparently, he'll wait for more requests. Wrong kind of analogue on the line, evidently.

And it's not a great list because, as I said, I can't remember. The mouse is less preferable to the trackball, which does perform splendidly on various shoot-em-ups. On that count, I would disagree that an analogue control isn't as nice as a good joystick.

[ThomasHarte]

EDIT:
There is a quite recent thread on lemon about this very subject! http://www.lemon64.com/forum/viewtopic.php?t=61515
He's focussing on the 1351 analogue mouse and seems less than impressed with the joystick style 1350 mouse.

I tried a device similar to the 1350 on the SAM Coupé, i.e. it plugged into the [Atari-style] joystick port and attempted to report mouse motion as though it were a digital joystick. It was terrible. All the flaws you'd expect. The device has to produce pulse-density modulation but has no idea how often it's being sampled at, so ends up being exceedingly conservative.

I'd say it was a little different in the C64's case because the machine was able to open the disk drive channel and communicate unimpeded, regardless what gadgetry the 1541 had inside - or any subsequent storage system imitating the protocol. You can't just take that plug-and-play for granted with every stock BBC. Also, the 1541 was a whole additional computer system, freeing up the Commodore for new tasks once complex drive routines were commanded. Existing protocols could be overridden, as the BBC couldn't do to my knowledge.

And it wasn't the 1541 drive's fault for being so slow. The 64 was so rushed through development that the team had no time to iron the bugs from the transferred fast disk system they had. Subsequent software and cartridge products (including games or demos with drivers inbuilt) mostly cured this, making the 1541 faster than the BBC system.

I actually think that to an extent the serial bus was a detriment for the user — instead of having normal DOSy commands like every other platform, like a CAT or DIR, you've got that LOAD "$",8,1 which the drive uses to get its catalogue then format it as though it were a BASIC program and ship it over as a listing.

That said, I'm aware that Commodore backed itself into the speed problem corner not once but twice through separate errors (the 6522 shift register race condition on the Vic-20, the missing trace on the C64) and admire not just the agility in getting anything working at all but also the aggressive cost streamlining that let them supply a whole second computer masquerading as a disk drive, still for less than the competition could supply a mere dumb disk drive.

EDIT: from the emulator author's point of view though, the 1541 is lovely. The processor is well defined, it runs a readily-available ROM, and the drive's memory map documentation and the serial bus documentation are not all that difficult to figure out. Since you're presumably already got working 6502 and 6522 code if you're writing a Commodore emulator, adding disk drive emulation is very easy. The main issues I encountered were that Commodore's approach to interfacing the serial bus at both ends seemed to be to flip a coin on each signal as to whether to invert. So half the time people have documented the various inputs and outputs the wrong way around. I ended up using the ROM disassemblies as authoritative, as no single document seemed to be sufficiently trustworthy.

[Commie_User]

Hmm. I appear to be speaking with a sensei here I can't see that a serial drive bus must entail this LOAD "$",8 nonsense. Indeed, I fail to see how it matters as the Action Replay cartridge made the drive blisteringly fast and returned a disk catalogue without wiping your BASIC listing.

And on a machine of the Commodore's vintage, serial seems as good a system as any to load and save programs quickly. So I'm certain that had Commodore allowed enough time for tailored disk commands and the later BASIC used in the PET, the 1541 would have been invincible. Indeed, given the technoid culture of the BBC users, you would have thought Acorn would have released this fat drive with the second computer inside.

[ThomasHarte]

Hmm. I appear to be speaking with a sensei here I can't see that a serial drive bus must entail this LOAD "$",8 nonsense. Indeed,

It clearly mustn't, as evidenced every time you plug in a USB drive. However the issues raised were (i) chip count; and (ii) what was built into the base machine. This is relevant to (ii). The command set Commodore built into the ROM had load and save but not catalogue / get directory / whatever. Therefore the nature of the built-in serial bus caused the 1541 to have to implement a user-hostile workaround.

I fail to see how it matters as the Action Replay cartridge made the drive blisteringly fast and returned a disk catalogue without wiping your BASIC listing.

It matters only as relevant to the original claim: "even the Commodore 64 could run a mouse without a new chip. Same for a disk drive". So the issue is how well the Commodore could run a disk drive without a new chip (on its local bus, to be sensible).

And on a machine of the Commodore's vintage, serial seems as good a system as any to load and save programs quickly.

The drive itself is physically serial so it's not just as good a system as any, it's the most natural. It's just a shame the 6522's race condition forced them into a CPU-driven solution on the Vic-20, and then the unrelated board-layout mistake forced them to keep it on the C64. Indeed, to have to slow down the drive because the C64 had a less regular and, in PAL world, a slower processor than the Vic-20. More than ameliorated by the VIC-II and the SID, of course. The comparison is relevant just as to the topic of loading from disk.

So I'm certain that had Commodore allowed enough time for tailored disk commands and the later BASIC used in the PET, the 1541 would have been invincible. Indeed, given the technoid culture of the BBC users, you would have thought Acorn would have released this fat drive with the second computer inside.

Acorn was more into pumping the machine full of ICs than the peripherals. And picking terrible, inefficient, hard to source disk controllers.

... and let's not be silly about this. One can (easily) complain about Commodore's implementation but the machine was almost all-conquering. If Thatcherism is an appropriate way to measure anything that happened in the '80s, that unambiguously makes it the best.

[Commie_User]

The Commodore was a conqueror. I still have three on the wall, two factory conditions (somehow) in backup and stacks of music perephery for my chiptuning. My only complaint is that the MIDI has stopped working and, even then, that's WinVice.

(Funny that. Different images of proven-working MIDI software, fresh emulator downloads, changes of PC, OS and MIDI hardware and still it's dead. Original hardware rules!)

EDIT: Oh wait, it's back again. FFS! (But in a good way.)

[1024MAK]

Um, most, if not all the floppy disk drives used the world over (Shugart Associates and the IBM PC variant) are all serial...

The chip count does not really matter. It's how the hardware and system software are implemented that matters.

Leaving FDDs aside, in terms of mice, mouse, track balls, joysticks and controller pads, there are many ways of actually making this work. Before deciding what is best, you need to define in detail what it is you want and how you would like it to work, from a users perspective.

The opto pulse, ball mice only have a ball, the rollers and bearings to wear out. There were (or there were attempts) to use 360 degree variable resistors with no limits, stops or breaks in the carbon track. These were the analogue mice.
But these will wear out. And there may have been other problems. So these never caught on (I'm not sure if any/many were sold). Not intended for the Beeb IIRC.

Mark

[ThomasHarte]

Um, most, if not all the floppy disk drives used the world over (Shugart Associates and the IBM PC variant) are all serial...

The chip count does not really matter. It's how the hardware and system software are implemented that matters.

No disagreement; my subjective retwlling of the conversation is that it went: Commodore managed to ship a disk drive that required no extra chips; actually it came with the most chips; but it interfaced via a standard bus and none of the chips went into the main machine; but that's a terrible bus; but serial buses in general are clever.

I'm also sure that Commodore benefitted a lot from constructing something using only chips that the manufacturer they already owned were already producing. There's a lot to admire in design by constraint.

[ash73]

I used to have a MAX desktop ROM in my BBC model B, I even found a copy to run in BeebEm. Looks nice but doesn't do much really.

[Commie_User]

Looks good, though. There must be a few good utilities with it and quite nice to boot code and view data and archives.

[cmjones01]

Back in the day, around 1987-1990, I did loads of work on my BBC using the AMX tools, especially Pagemaker. Yes, 32K of RAM wasn't enough, so the mouse utilities lived in their own 16K ROM, and the Pagemaker software was in two 16K ROM images loaded into sideways RAM banks. One neat thing about it was that it handled relatively high-resolution pages bigger than the screen could handle by paging to and from the floppy disc, which it did quickly enough not to be annoying.

It all worked pretty well for an 8-bit machine. I've still got the mouse and AMX ROMs here, and the machine for that matter!

Regarding how the hardware was done, I think Commodore's serial bus was a very clever idea, especially being based on the IEEE488 bus which is still popular in the industrial and scientific world, but spoilt by the standard rather slow implementation. Acorn took a different direction. They didn't invent anything new for the peripheral connections but just used industry standard interfaces, so more or less any random disc drive or printer would work with the BBC. However, they did make a daft choice of disc controller chip!

Chris

[Commie_User]

Handyscan for the C64 saved in higher than screen res' too. And though I was playing with this stuff years after anything could have been useful, I never did find an image standard converter to run 'em in DTP packages.





Still, here are my experiments. They look old newspapery but that only meant the C64 delivered that professional look:

icl_user[1].jpg (51.54 KiB) Viewed 4648 times