Super Mario on the BBC?

[Commie_User]

I found Drain Mania, which is close to the original Mario: https://www.youtube.com/watch?v=d5DtsTaf_Mo


Stairway To Hell says Amnesia is like it, though it's pretty rubbish. But I won't take no for an answer and I say there surely must be a homebrew somewhere. Or even a demo.

Anyone know?

[tricky]

The 6845 doesn't lend itself to slow horizontal scrolling, so there aren't many horizontal scrolling games. You can do it at 25fps, but it looks jerky.
I think my rally-x is the only demo to use the horizontal sync pulse width method (as per edge grinder on the CPC) on the beeb. There are some games that scroll 1/80th of the screen at 50fps, but that is easy to fast for supper mario.
Sorry, if you meant the original mario game.

[Commie_User]

Interestinger and interestinger. It looks like someone's managed Super Mario on the Atari 2600, though: https://viciogameblog.com/2012/08/30/ac ... tari-2600/

Though I don't speak (I assume) Spanish, it looks and sounds like an Atari with extra chips in the cartridge. The tape game adapter once out for it was similar. Now that's something I'm extremely surprised the homebrewers and publishers never came up with - BBC chips for enhanced/tailored graphics and such. Not that I'm aware of.

[tricky]

The B+ would have been a good candidate for a sprite overlay chip, or even the master.
I guess there are many ways to add tile and sprite hardware, but with such a small market, I guess it would have been a case of chicken and egg.

[Commie_User]

Hmmm. Though I've seen BBC daughterboards, implying routes may have been open for all kinds of EPROM experiments, I still have to ask how feasible it may have been for hobbyists to get flashy projects running. After all, BeebSID didn't seem to do too badly.

And the BBC was supposed to unlock all kinds of options usually closed to the C64 or Spectrum base, after all.

[davidb]

I don't think it was cost effective to add custom chips to games on systems where games were normally published on cassette or disk. Doctor Who and the Mines of Terror being an exception on the BBC. On other home computer systems, games needing extra hardware didn't even make it to publication.

Custom hardware did appear for use in the TV industry. Other boards allowed the palette to be changed (see this discussion).

[1024MAK]

On most computers, adding extra hardware to increase the capability of the video system is not easy, as nearly all the original computer boards have no provision for this. Sometimes if the video system chips are in sockets, it is possible. On the Beeb, it would have been possible to remove the Videoproc / video ULA chip. Plug in a PCB module, then plug the Videoproc / video ULA chip into this PCB module. Then a new video chip could mix in new graphics with the existing Videoproc / video ULA chip's output. But as said above, very few games would have used it, even if such a device had been available.

The only time such a add-on got used, is if it came out early in a computers life, and was a must-have. Hence many software writers would then support such an add-on. Otherwise, apart from a handful of games, such devices were mostly ignored.

Mark

[Commie_User]

I don't think it was cost effective to add custom chips to games on systems where games were normally published on cassette or disk. Doctor Who and the Mines of Terror being an exception on the BBC. On other home computer systems, games needing extra hardware didn't even make it to publication.

Maybe that's a drawback of the BBC lacking a cartridge port. Actual upgrades to central hardware may not have been necessary. Many software chips were indeed released for not too much money and a just bit of extra ROM could have expanded the wow factor of normal games. Cartridges for that era's machines were reputed to be flashier than the tape counterparts.

[Rich Talbot-Watkins]

I've always imagined a Mario type game on the Beeb would use the style of horizontal scrolling used by Exile, i.e. the player character isn't centred, but when you reach a margin position, it starts off a character block scroll until the character is now at the opposite margin. This would become a continuous scroll if the character starts moving at one character block per frame. This type of scrolling still feels pretty smooth and unobtrusive. You could still scroll pixel-by-pixel vertically.

[RobC]

There were some add-on boards that expanded the Beeb's graphics capabilities.

I've mentioned the Wild Vision PaletteMate, Mike Cook's Chameleon and the Saturn board on here before. All gave a palette of 4096 colours with the PaletteMate offering 16 true colours in mode 2. I think the PaletteMate replaced the video ULA - I've been thinking about creating something similar for a while now.

There was also the Prisma3 and some Pluto graphics boards but these were designed for broadcast graphics and, although they blew the 8-bit competition out of the water, they were very expensive.

There was also a sprite board that I wasn't aware of BITD using the TMS9129:
http://8bs.com/seemonitor.htm

There's some info from Paras Sidapara (who did the initial work on Repton: The Lost Realms):
"An amazing piece of hardware!!! Back in the eighties when I was at school, I used to program that thing for games! The beeb itself runs in Mode 7 and this thing custom generates the display with some fancy Texas Instruments controller. The unit used to be sold by Logotron along with a Logo extension disc which added commands to their Logo interpreter to give support in the language for loads of turtles. It put the Atari 800 and C64 to shame, though was a bit unreliable."

[sirmorris]

I was pondering something just this morning which was prompted by the Pi 'vga' adapter for the Atom in particular, and the concept of pi co-pros in general.

What about a combined Mathbox/vector generator and high speed line renderer module for the pi? This would make an arcade perfect version of the early Atari vector games possible. The game code is already 6502, with the rendering of vectors and mathematical processing carried out off-board.

Hoglet?

[timmy]

That BBC Sprite Board sounds intriguing - I wonder if it still works or if the software exists... would love to see the output from it!

But back to the start of the thread, if horizontal scrolling is so difficult how did Frak, Castle Quest, Repton, Stryker's Run or even Defender manage it?


tim

[tricky]

1/80 of the displayed area hardware scrolling is easy, but about twice what most continuously scrolling games use.
1/160 is possible, but only under some kind of emulation or on a CRT and requires some careful work.
Software scrolling is OK, but if there is much to display, then it is very hard to hit 50fps.
I don't remember exactly what smb needs, but it feels like mode 1 one pixel scrolling. This is only practical in hardware by turning thes screen on its side - as some arcade games do (although usually for different reasons).
There are plenty of games that do software scroll and are fun, I hope Jeltron falls into this category.

[jbnbeeb]

I 'm slowly but surely coding a game that does 50fps sideways scrolling that appears to scroll two mode 1 pixels per frame. It's master 128 only, and uses double buffering. I have two sets of sprites, one for each screen. The second screen sprites are offset by two pixels when compared to the first. After displaying both screens, I then hardware scroll by 4 pixels (one char address).

It's master 128 only because the BBC b doesn't have shadow ram to fit in two 20 K mode 1 screens. The b plus has shadow ram that can be used for video but it can't be written to directly (you have to use Os calls/basic) and so too slow for games.

I'll be demoing at London RiscOS show October 29th and Bolton Abug. It's looking good now but is still far short of being a game presently.

Tricky gave me the idea for this. Thanks tricky

Maybe Mario could be done with this technique.

[RobC]

The second screen sprites are offset by two pixels when compared to the first. After displaying both screens, I then hardware scroll by 4 pixels (one char address).

How are you managing the offset sprites? Is it a bit of a nightmare to keep track of them?

Thinking about it briefly, as it's Master only, could you put all the sprites in 2 x 16K of sideways RAM and then page in the correct bank depending on which frame you're plotting. This would allow the sprite copies to be at the same addresses in memory but be physically different.

[RobC]

That BBC Sprite Board sounds intriguing - I wonder if it still works or if the software exists... would love to see the output from it!

It looks a fairly simple design and the TMS chip is still readily available.

A really exciting possibility might be emulating a Prisma3 on a Raspberry Pi - IanB mentioned this a while back and it would bring fantastic capabilities to the Beeb.

[jbnbeeb]

How are you managing the offset sprites? Is it a bit of a nightmare to keep track of them?

Yes it is a total nightmare! It's taken months of (on/off) debugging and rework of sprite position update routines. It's working now though

When I was at Cambridge ABUG, showing the code to Tricky and Kees, I got some good tips which inspired me to do what I should've done months back. I scrapped several routines and rewrote them. By this point, I'd fully worked out the logic and had had it in my head for months, but the code had become repetitive and somewhat muddled. It only took me half a day to rewrite all the sprite update logic. The code was a quarter of the size and only had two bugs in it which I found quickly. Do coders call this re-work "re-factoring" ?

Thinking about it briefly, as it's Master only, could you put all the sprites in 2 x 16K of sideways RAM and then page in the correct bank depending on which frame you're plotting. This would allow the sprite copies to be at the same addresses in memory but be physically different.

Currently I'm just using one bank of s/w ram. The idea is a good one, but it might still be a bit of a pain for sprites which move unpredictably. Depending in which screen buffer the player decides to move left or right, movement on a given buffer will need to start from either an offset or not-offset sprite. I use tables to store properties for each sprite. Within the tables, I use pointers to point to the relevant sprite plot data and flip these around as necessary for the correct sprite (offset/no offset). I dunno if I described that well. If I see you at London RISC OS I'll show you the code

[tricky]

Glad to hear it's moving along, but I hope you'll have the jbip music at the ready to keep those sound boys under control

[RobC]

Currently I'm just using one bank of s/w ram. The idea is a good one, but it might still be a bit of a pain for sprites which move unpredictably. Depending in which screen buffer the player decides to move left or right, movement on a given buffer will need to start from either an offset or not-offset sprite. I use tables to store properties for each sprite. Within the tables, I use pointers to point to the relevant sprite plot data and flip these around as necessary for the correct sprite (offset/no offset). I dunno if I described that well. If I see you at London RISC OS I'll show you the code

Ah I see - thought my idea might be a bit simplistic!

Managed some motorway driving yesterday so fingers crossed I'll be able to make it on Saturday

[algenon_iii]

I don't think it was cost effective to add custom chips to games on systems where games were normally published on cassette or disk. Doctor Who and the Mines of Terror being an exception on the BBC. On other home computer systems, games needing extra hardware didn't even make it to publication.

Maybe that's a drawback of the BBC lacking a cartridge port. Actual upgrades to central hardware may not have been necessary. Many software chips were indeed released for not too much money and a just bit of extra ROM could have expanded the wow factor of normal games. Cartridges for that era's machines were reputed to be flashier than the tape counterparts.

They had a go at cartridge slots with the Electron Plus 1, but it was too little too late. It also showed that the if cartridges weren't standard on every machine then nobody (other than the computer maker) would bother producing games.

I'm sure someone will correct me if I'm wrong, but the Acornsoft Plus 1 games cartridges were loaded into RAM like the tape versions. However, as I understand it, the cartridge ROMs could be directly accessed which would have allowed the games to run faster than they would normally. Whether that would be at or near BBC speed I don't rightly know, I guess it depends on if stuff like hardware scrolling was used. That might had got around the problem the Electron had where games had to use Modes 4 or 5 instead of 1 or 2.

[Commie_User]

Another reason cartridges failed, I think, was the fact quality control was only lavish enough by the 90s. Look at the overall lush and slicker (by comparison) games on the NES, Master System or Super Nintendo. Systems designed for best cartridge performance with higher ROM capacities. Look at the high watermarks of the 16-bit era, like Donkey Kong Country.

They were packed with system upgrade chips and - at their best - greatly justified high price tags, in a way that Platoon or the Untouchables on cartridge wouldn't have.

[davidb]

I'm sure someone will correct me if I'm wrong, but the Acornsoft Plus 1 games cartridges were loaded into RAM like the tape versions. However, as I understand it, the cartridge ROMs could be directly accessed which would have allowed the games to run faster than they would normally. Whether that would be at or near BBC speed I don't rightly know, I guess it depends on if stuff like hardware scrolling was used. That might had got around the problem the Electron had where games had to use Modes 4 or 5 instead of 1 or 2.

All the Acornsoft games on cartridge use the ROM filing system as far as I know, which is a real shame because I'm sure they could have made the games run directly from ROM. There might even have been a slight speed boost for certain kinds of games as the CPU will access the ROM at full speed, though I think many of the published games may have been accessing the memory so much that the overall effect would have been more modest.

I converted my games to run from ROM because I wanted them to start immediately after boot-up, if possible. Castle Raider feels quicker when run from ROM but is possibly slightly too "slippy" compared to the tape/disk version.

[1024MAK]

Forgive me if I have got this wrong (my knowledge of Commodore's computers is a bit limited), but with computers (not consoles) available in the UK, where users had a choice of tape/disk/cartridge, the majority of users went for the tape or disk media. Various 1980's computers could use cartridges, but not many cartridge for any computer (which could use tape or disk) were produced.

If the Election had been fitted with a cartridge slot at launch, the story may have been different. Imagine a 32k byte cartridge with a machine code game that could run much faster (maybe nearly 2 MHz). I say nearly, as the code in ROM would run at 2 MHz, but would be affected by any reads or writes to RAM. As most games access the screen memory a lot, the speed up may not have been as much as expected.

Ahh, but we can dream...

Mark

[tricky]

You might have got more direct beeb ports and less dedicated stuff; settings swings and roundabouts.

[Commie_User]

Well it's just that I'm thinking, given even homebrew Mario on the Spectrum, there must also have been some party thing somewhere for the BBC: https://www.youtube.com/watch?v=IqurbCENCOM



There's always somebody who made things which everyone else said was impossible.

[tricky]

That does look interesting, mode 4 (but 256x192) black and white (or whatever background colour).
With sideways RAM, there may be enough room to unroll things enough using similar tweaks to the landscape.
It could be done at 25fps, easily with shadow ram, but would it be worth the effort?

[davidb]

I'd prefer a Sonic port if someone thought of adapting a console game to the Acorn 8 bits. I've never been a fan of the Mario games.

Rant: It seems that the NES always has to have a prominent place in the histories of computer and console games that are published on mainstream sites dedicated to gaming. It's like the comfort blanket for a generation of US gamers and even with some UK gaming types, though I can't help feeling that there were precious few people actually playing NES games in the UK when the console was still current. I understand that it was an influential console but I think it gets a disproportionate amount of attention now.

[Commie_User]

Hmmmm.

I agree that the NES seems to get the top billing for 8-bit retroness. But then, it seems more a case that we were out of step with the world because I don't think any one machine truly dominated across Europe, the way the NES did in the US. So looking back, the NES gets more single coverage.

But that's our individualism for you. And easily solved today.. buy the lot! Bit more expensive now than before the Credit Crunch but we can do what we never could just a couple of decades back - buy a fleet of old units with games and call that our arcade.

Japan did well, though. They flopped with computers, which were more our department but when it came to arcades and consoles, well... a NES was typically slicker, typically ran more expanded games and was often easier to control than a Beeb.. or even the 64.

And when you're looking a retro machines - like it or lump it, world - the games are most prominent.

[tricky]

OK, I've been doing some more experiments with mapping and drawing the first SMB level, without any "sprites", just the landscape and only displaying the top 8 pixels of the "floor"'s 32, I think I can scroll up to 8 mode 4 pixels per frame in under half a frame, unless I've missed something or got my maths wrong!
I will try and get a demo together when I next get some time
Oh dear, yet another distraction

[Commie_User]

Whoa! Fantastic!

Thanks. (That is, if you're doing it for me, specifically!)