
Pascal Compiler for the C64: Introducing Turbo Rascal SE - pjmlp
https://lemonspawn.com/turbo-rascal-syntax-error-expected-but-begin/
======
denton-scratch
I used to have a job writing Pascal code. I liked it; it was easy to predict
how it would behave. It was verbose, but in exchange it was easy to read stuff
written by other people. And I've long thought it was a mistake to abandon
strong typing. It's good if the compiler (or interpreter, or whatever) can
report silly mistakes at the earliest possible stage. (I knows most people
disagree, stop with the rock-throwing!)

I never tried to write a Pascal compiler, but I think it is pretty easy - I
wrote a source-code debugger for one implementation of the language, which I
think involved reverse-engineering the targeted compiler (can't really
remember - too long ago). I had never before encountered a source-code
debugger for any language at all (other than 8086 Assembler, which only just
counts).

I just thought it was a cool idea, and one that would help me in my work. It
was a "hobby" task, and I had a full-time job, a young wife, and kids. It
can't have taken more than a handful of weekends.

~~~
folkhack
I was a kid learning programming languages and after QBASIC I struggled to
find a language that I could grok as a 10-12yr old right before the turn of
the millennium. I shared with my uncle that C and C++ were difficult for me
and he gave me a whole bunch of Turbo Pascal books... And I fell in love =)

Pascal was an approachable language and was exactly what I needed at the time
to push forward, revisiting C in my highschool years. I built dumb Dragon
Warrior clones, homework helpers, etc. It was super readable for me too.

Of course I look back with rose tinted glasses on but Pascal was a huge part
of my programming growth - I will always remember it fondly!!

~~~
pjmlp
To join my voices to the choir.

Timex 2068 Basic, Z80, GW-Basic, Turbo Basic, 80x86 and then came to learn
Turbo Pascal (started with 4.0 and did all of them up to Delphi 2).

Thanks to this path I got to learn systems programming in high level mostly
safe languages, modules, OOP and my very first framework experiences, Turbo
Vision (OWL, VCL as well).

For me this was a very lucky path, because I never got tainted that C and C++
were the only God sent programming languages for systems programming.

And best of all, I never had any issues to deal with pointers in C and C++.

------
ebg13
This looks like a Pascal compiler _targeting_ the C64.

If you want a Pascal compiler _on_ the C64, see:
[http://www.gammon.com.au/GPascal/](http://www.gammon.com.au/GPascal/) and
interview with the author at
[https://web.archive.org/web/20180911174601/http://www.superc...](https://web.archive.org/web/20180911174601/http://www.supercoders.com.au/blog/nickgammongpascal.shtml)
and the author's writeup at
[https://www.gammon.com.au/forum/?id=11203](https://www.gammon.com.au/forum/?id=11203)

~~~
tluyben2
I used one (Pascal compiler) for half a decade on the MSX; I guess the C64 one
would be equal or slower speed. We bought (1986/7 I think) a second MSX for
compiling and testing + a monitor switch, so I could keep working during
compilation and crashes. It was painful. But I did like it (and still do
sometimes, but my MSX has SD cards, a lot more memory and I have many of them;
also, most of the work can be done on an emulator anyway before I test it on
the metal).

Edit; actually remembered I had that setup before using/having TP I think; C
and asm compiling and crashing were equally annoying. I switched to TP because
I opened a company with a family member and he did all in TP and already had a
large (I thought at the time) codebase.

------
MegaDeKay
This guy has a fine sense of humor. From the website...

 _But.. why?_

 _The author had a C64 as a kid, but never got the hang of understanding
proper programming until the x86 era of the 90s. This is his way of mending
the hole in is soul. In addition, he hopes that he’ll get filthy rich & famous
off this project._

 _Pricing_

 _Free of charge. How the “rich” part will be achieved is still up for
debate._

The demo video linked from the website is well worth watching as well. Some
punny stuff in there, like "Rogue Burger One".

[https://www.youtube.com/watch?v=WhJSG7TiHAE](https://www.youtube.com/watch?v=WhJSG7TiHAE)

edit: spelling

------
hybrids
_“Turbo Rascal Syntax error, “;” expected but “BEGIN”_ is a considerably
strange name...

~~~
xyproto
Typical Demoscene humor. Also check out GNU Rocket
[https://rocket.github.io/](https://rocket.github.io/)

------
andrewstuart
Turbo Rascal Syntax error, “;” expected but “BEGIN”

Is a very strange product name. Only a programmer would think this would not
damage the success of the project.

I nearly closed the page as soon as I hit it, thinking that somehow I had
landed on some page where someone is trying to resolve a programming problem.

~~~
romwell
> Only a programmer would think this would not damage the success of the
> project.

It's a _Pascal_ compiler for _Commodore 64_.

I don't think naming is _the_ factor that would inhibit the widespread use of
this compiler.

Not to mention, it's a good enough name: everyone's going to remember "Turbo
Rascal", which conveys all the information necessary (like Turbo Pascal, but
not really).

------
Mountain_Skies
It's a shame that compilers were so expensive during the eight bit era. The
built in Basic in most home computers of the era gave many a good start on
learning programming but it was a huge step up in commitment when you wanted
to go beyond Basic.

~~~
stevekemp
I guess I was lucky in the the computer I started with, the ZX Spectrum, had a
pretty decent manual. Which also managed to cover assembly language.

So my route to coding was first of all BASIC, then assembly language. At the
time I was 11-12 years old and it didn't seem like a huge jump, though I guess
I can see it was now!

I think my learning went BASIC -> Assembly, on the z80. Then later QBASIC on
the PC to assembly, edited with debug.com, and after that I started doing
"real" programming with C, Perl and all the other languages that followed.

I'm still sad that most people don't have any built-in programming environment
to their computers that is so easy to start with these days. I guess
javascript is close, since everybody has a browser. But it's not quite the
same.

------
ncmncm
I think the Rascal dialect was, originally, a Reed College CS undergraduate
project, in the early 1980s, before everybody knew that C was going to drive
all before it.

But it wouldn't be surprising for somebody else to use the same name.

------
goatinaboat
I wonder if it can target the BBC Micro too

~~~
rzzzt
"BBCM" is present in the target system dropdown for project settings; don't
know how much actual support is there, though.

------
Razengan
I love seeing things still being made for old computers.

------
tiles
The impressive part is how you can write a game for one of these systems, and
easily port it across a variety of 8-bit platforms. That's hardly true for C
code and definitely not true for assembly!

~~~
tom_
Is this really going to be true? Aside from the 6502, the overlap between the
supported systems is approximately 0! I'd expect creating a cross-platform
product to be no easier than it would be when working in assembly language.

~~~
ddingus
There are a set of basics, given some tradeoffs are baked in.

On most machines, one can get a bitmap. Addressing varies, but the rest makes
sense. Give people a software blitter and that is portable.

Colors. Stick to the basics, that is portable ish.

Most machines can make a sound, display a character, bitmap, take keyboard in,
etc...

Now, if one wants to see closer to peak performance, yeah. That is a labor of
love at this point. Asm, hacks, the whole nine.

~~~
vidarh
Software blitting to a bitmap was too slow to be viable on most of the
supported machines. Bitmap mode was only used for a very few games on the
8-bit versions of these due to how slow it was. On some of these you'd have to
fake bitmap mode with custom character sets. E.g. the VIC-20 can at most give
you around 160x160 pixels using redefined character sets. Conversely on the
Amiga you have no other choice but to use bitmaps.

So just trying to blit in anything remotely portable manner would be a problem
in itself. E.g. on the Amiga you can place things anywhere you want. On the
C64 you'd place things on character boundaries (or take seconds to draw
images, like a few adventure games that used bitmap mode did), and if you
needed smoother movements you'd either smooth-scroll the entire screen or have
two different versions of graphics, or use hardware sprites (even sometimes
for background features).

If you want a common lowest denominator you pretty much end up with a mostly
text-display (~22x23 characters unless you ditch the VIC-20), monochrome,
unless you ditch the PETs, only beeps for sound, unless you ditch the PETs,
4-5KB total for code and assets (unless you ditch the VIC-20 and some of the
PETs) and so on.

It might be a "fun" exercise for the sake of it to see what the best you could
do in a portable manner, but it would really boil down to what the best you
could do on one of the most memory-limited PETs is, I suspect.

I mean you certainly could do Infocom style text adventures... Small ones
anyway.

If you cut it down to the NES, C64 and Amiga (and maybe Plust4), then you'd be
able to start doing something somewhat more interesting, but the architectures
are still so wildly different that you'd end up something unable to stretch
the capabilities of any one of them. For slow-ish moving strategy dominated
games it might work.

E.g. Sid Meier's Pirates! was partly written in BASIC on the C64, and while
the Amiga port is an upgrade it's a small-ish upgrade (more colours, higher
resolution mainly). That kind of game would be feasible to do portably if you
exclude the VIC20's and PET's, and stick to C64-level graphics. Games like
Defender of the Crown, likewise, though they'd lose the graphics quality on
the Amiga that was 90% of the appeal of the Cinemaware titles on the Amiga
(though ironically, Defender of the Crown is often considered better on the
C64 (and some other platforms) - they fixed various parts of the strategy
elements of the game).

~~~
ddingus
Actually, I have done software blitting on Apple 2, C64, Atari 8 bit.

That is the only way things got done on the Apple 2.

Look at this:

[https://youtu.be/t7_hvzIaqxk](https://youtu.be/t7_hvzIaqxk)

On an Apple 2, using both pages of bitmap memory, it was possible to move some
objects reasonably back in the day with p code Pascal. Several of us did that
in high school.

A compiled version, straight to ASM would do better. What I linked was the
peak possible with hand coded blitters.

There is a low, middle ground that is useful. If one can include a library,
written in ASM for each machine, more is possible.

Plus 4, C64, Atari 8 bit, Apple 2, Color Computer, and others all supported a
4 color bitmap, ranging from 128 to over 160 pixels.

Tons of games were written for those machines using software objects. NES does
not quite fit here, though I suppose it could. I have not programmed it for a
bitmap.

I think there is a wide range of expectations here. There is also groups of 8
bitters. Nothing but text is truly portable across them.

The basics I mentioned aren't AAA title grade. They can be fun grade,
depending. And on the more capable 8 bit machines, possible.

Edit: you mentioned, stretch the capabilities. Yeah, I was not speaking to
that at all.

Doing a stretch type work will pretty much take assembly language.

But, there are exceptions. Take a look at this Apple 2 project.

PLASMA is a high level, ish high code density environment, coupled with 6502
assembly. Perfect for big RPG games.

[https://m.facebook.com/LawlessLegends/](https://m.facebook.com/LawlessLegends/)

Plasma itself is pretty interesting from an 8 bit development standpoint.

~~~
vidarh
You certainly _can_ do it, but the point is you can't do it in a generic way
across those platforms without ending up with something _extremely limited_ to
the point that if you want to do that, why bother targeting anything but e.g.
VIC-20 or PET anyway? Because it will end up looking like a VIC-20 or PET
program if you target it at the lowest common denominator.

Most of the listed machines run 6502's at too low speed to be able to move
much graphics. It's not possible to do more than one write every ~8 pixels on
a C64 if you want to actually write different values (you can demonstrate that
easily by using a raster interrupt and repeatedly changing the background
color as fast as you can) outside of lines where the vertical blank is
enabled, for example. We did that a lot for demos - doing raster bands like
that was a popular effect for a short while.

So you end up either limiting yourself to a handful of small objects, like
Robotron; drop your effective framerate and accept glitches - like Robotron;
or use custom code for each platform. Trying to do an efficient portable blit
routine across those platforms is pointless. Compare C64 Robotron [1], which
was considered outdated in terms of graphics by about 1983. It does _not_ use
bitmap graphics, but a combination of sprites and character graphics.

Which is back to the lowest common denominator issue: Sure, you _can_ do
software blitting, but you end up with something that wouldn't pass for a
reasonable VIC-20 game even. Unless you exclude the PETs, you're stuck with
monochrome; with the VIC-20 you're limited to 160x160 pixels, but even at only
160x160 pixels you're able to move just a fraction of those per frame. Then
you have colour issues - even if you drop the PETs:

> Plus 4, C64, Atari 8 bit, Apple 2, Color Computer, and others all supported
> a 4 color bitmap, ranging from 128 to over 160 pixels.

Yes, so now you've excluded a bunch of the platforms on the supported list. If
you do that, you can get somewhat more reasonable results. But you still end
up with additional considerations, as the way they are stored in memory varies
significantly. E.g. on the C64 a bitmap consists of a 2x 1000 byte block of
40x25 colour settings (screen ram and color ram as used in the character
graphics modes) + 4000 bytes of 160x200 pixel values, which each byte
representing 4x2 bit pixels, where for each pixel 00 = background and 01, 10
and 11 representing a nibble each from the 2x 40x25 blocks. This means that
you can't blit anything beyond a 4 colour image to an arbitrary position - if
it doesn't fall on a 4x8 character boundary, and you use more colors than
that, you get ugly colour bleeds.

So now, now you're down to 4 colours _or_ accept colour bleeds that would make
anyone with a C64 draw derisive comparisons to a Spectrum, or you'll accept
the need for a custom blit function. In which case, why the hell would you use
bitmap graphics on the C64, when working within the constraints above makes a
combination of character graphics and sprites far superior.

There's a _reason_ why games were rewritten for each platform back in the day
- it was less effort than trying to come up with some lowest common
denominator that didn't just annoy everyone on every platform.

> Tons of games were written for those machines using software objects. NES
> does not quite fit here, though I suppose it could. I have not programmed it
> for a bitmap.

For the C64 at least it was very much the exception. It happened, for games
with very static screens, though rarely even then, because it would have been
an utterly idiotic thing to do for anything but mostly static graphics. In
fact, you'll see a lot of later C64 games _did_ do a lot of "blitting". Except
they didn't blit pixels. They blitted whole characters, using the character
mode. Afterburner and Barbarian II are good examples of this, that mix sprites
with character mode. Last Ninja I'm not sure about - they spend a lot of time
(seconds) "rendering" some of the screens, but I haven't looked at them
closely enough to know if they did that using character blocks or bitmaps
(there's clipping along 8x8/4x8 boundaries, but that might be a rendering
artefact whether or not they use character mode; in either case they didn't
use that for _all_ the graphics - they also overlaid sprites on part of the
screen as a poor mans z-buffering).

> I think there is a wide range of expectations here. There is also groups of
> 8 bitters. Nothing but text is truly portable across them.

Which was exactly my point. The lowest common denominator of the platforms
listed on the linked page is ~21x21 characters in monochrome, with beeps for
sound and ~4K RAM. You can technically get some semblance of bitmap graphics
by using redefinable character sets on the ones that don't have a dedicated
bitmap mode.

If you try to do something portable, the lowest common denominator is so
exceedingly low that it's not very interesting.

If you want to go past that, you either ditch a number of the platforms, or
you end up writing largely custom code for the graphics for most of them. Even
between the VIC-20, C64 and Plus4, while you _could_ reuse some code, it
rarely paid off - you ended up not exploiting the capabilities of any one of
them very well.

> Doing a stretch type work will pretty much take assembly language.

It's not even about assembly; even a hypothetical compiler that utilizes every
available cycle will not abstract away the sheer differences of even something
as basic as the memory layout of the graphics modes. And it's not about
"stretch" beyond expectations of the very early 80's. Commando was not
"stretch" in terms of C64 capabilities _at all_ \- it's pretty primitive [2] -
it's just using character level scrolling and sprites. The music is not
advanced for a C64 game (in terms of technically playing it; Rob Hubbards
soundtrack is iconic, but that's a separate thing), but it's far beyond the
abilities of e.g. a VIC-20 to reproduce faithfully. Commando level graphics
would be pretty disappointing even on the C64 today, because later games did
so much better. E.g. R-Type [3] style parallax is not achievable with bitmap
graphics on a C64 - it depends heavily on being able to do _bitmap scrolling
of the definition of a tiny number of characters_ while scrolling the screen
using the character mode. It combines that with sprites for most of the
enemies, and character blocks for most (all?) projectiles. A 6502 at 1MHz
simply does not have enough clock cycles to move that large parts of the
bitmap every frame. But this level is "standard fare" on the C64 - those are
the games we remember, because e.g. doing things like those parallax effects
is cheap and easy, and so was all over the place at the height of the C64.

So it's that if you seek a lowest common denominator even excluding the PETs
and VIC20, you end up with something that'd have seemed dated by about 1984,
_before_ most people with these machines got them.

I guess I don't see the point. I loved the C64, and I loved the Amiga, but I'd
get no joy out of seeing C64 software that looked like it belonged on the
VIC-20, or Amiga software that looked like it belonged on the C64.

[1]
[https://www.youtube.com/watch?v=oI05NfaNiAA](https://www.youtube.com/watch?v=oI05NfaNiAA)

[2]
[https://www.youtube.com/watch?v=cdGaZ8Fakok](https://www.youtube.com/watch?v=cdGaZ8Fakok)

[3]
[https://www.youtube.com/watch?v=Bft5BhWIzTU](https://www.youtube.com/watch?v=Bft5BhWIzTU)

~~~
ddingus
Well, I share your love and agree on most of what you put here.

My only real point is a software blitter library would permit quite a bit, and
be portable.

A secondary one was software objects got done quite a lot. C64 is actually one
of the worst case scenarios. It had a considerable amount of DMA interrupting
the CPU.

Apple 2 is a second worst case. No DMA, but addressing from hell.

The others, including the VIC 20, run faster and make a few more objects
possible.

By all means, write for the CPU directly to get what those machines can do. I
never implied otherwise.

But, if someone wants to explore a little, and wants to use C or Pascal,
etc... more can be done than expected.

Re: Tearing

Yeah, the Apple port of Robotron does all those things, but is also one of the
better ports. The action is there solid. So many ports did not actually
deliver.

Atari 8 bit is pretty terrible. C64 looks nice, but just does not deliver the
motion...

Sometimes it is about more than looking pretty.

~~~
vidarh
> My only real point is a software blitter library would permit quite a bit,
> and be portable.

But it really wouldn't be portable. Maybe you mean the software using it could
be portable. Because you'd need to account for totally different memory
layouts, totally different initialization, totally different movement rules if
you want to avoid color bleeds, palettes ranging from monochrome and up etc.
You'd likely end up with about as much code to try to make something like that
generic as you would writing separate more optimized versions for each
platform.

> A secondary one was software objects got done quite a lot. C64 is actually
> one of the worst case scenarios. It had a considerable amount of DMA
> interrupting the CPU.

It had _some_ , but not very much. The 6510 didn't access memory other than
every other cycle, so most of the time it ran unhindered. Some things would
change this - e.g. it "cost" two clock cycles per raster line for every sprite
that was present on that raster line.

It also cost you extra every 8th line when the VIC would need to retrieve new
colour data from RAM, but if that was enough to tip things over the line you
could "just" cut ~25 lines off the part of the screen you worked with and
you'd have freed up more cycles than you lost. Some games certainly did "play
games" with the display size, to cut the cost of graphics updates, but the
vast majority of those games did that despite not even using bitmap mode.

The reason we didn't use bitmap mode was not DMA, but that character mode +
sprites + raster effects was _so much faster_ for most uses.

> But, if someone wants to explore a little, and wants to use C or Pascal,
> etc... more can be done than expected.

It's not the language per se that is the issue (though most modern languages
are awful for 6502 platforms without _lots_ of restrictions due to stack
limitations); it is whether or not you write code custom for the specific
graphic chips in particular for those architectures, which tends to make up a
fairly substantial part of the overall game when you in most cases are looking
at single to double digit number of KB including assets.

> Sometimes it is about more than looking pretty.

Yes, but my point is nobody would have accepted the C64 Robotron either
already by ~1985. Game quality had moved on. By pure sales numbers alone, the
majority of people who remember these platforms fondly today got them after
the design of a game like Robotron was already outdated.

I just don't see the appeal of aiming for portability between platforms where
what you do to achieve that portability completely eviscerates what people
loved about that platform because the lowest common denominator is so far from
what people were used to. In that case, just write for the VIC-20 or whatever
matches your lowest common denominator directly.

~~~
ddingus
Yes, I do mean the software using it would be portable.

Consider it a display driver / primitive and call it good.

Old bitmap games have their charm.

Initially defines one or two pages, sets display registers, etc... done.

>movement rules

Blit needs two basics. One bit per pixel and two bits. That is it. Color maps
and such do not need to be a part of things, or the programmer can manipulate
them directly where they are available.

>whether write for gfx chips

Sure. Again, bitmap games have their charm. That is all. Trust me, I wrote to
those chips and that is a different thing.

Your comment on the C64 Robotron is interesting. Had they broke a few rules,
it could have delivered more like the Apple 2 did.

Players of Robotron would take it as the fast action trumps just about
everything else. I linked that title as a great example, because of that.

I was there in 85, and plenty of us played the crap out of Robotron on the
Apple and PC (given a fast enough one, lol) and played it because it delivered
what Robotron was about. Many did not enjoy C64 or Atari Robotron because
other trade offs were made. The arcade cabinet was common. The title was
relevant.

The best ports rendered quick to a bitmap just like the original did. Now, the
original had a 6809 and a blitter assist. That made for insane action, and is
not directly comparable when considering minor artifacts along the way.

Here's the thing:

You and I both loved those platforms for similar reasons. No argument. Making
something that can deliver across a more 8 bit machines does something else.

It does not take away from the greatness. When the demoscene gives up, I will
worry. New C64 / Amiga productions still happen, and still push it all in that
way we love.

But, there is a fun world of 8 bit gaming and such out there working
differently too. Most of that is on a 1 or 2 bpp bitmap.

That is really all to the comment I made.

Recently, I have been enjoying things on Apple, Spectrum, and soon maybe a BBC
Micro. Bitmaps and clever ways of delivering the goods. I found there are
things to appreciate, I would have not before.

The more the merrier.

8 bits are enough. Honestly, that people still create in that space is a lot
of fun. However they do that, I want them to do that.

Does not mean I would do it that way. But it does mean I would totally give
what others did a go.

~~~
vidarh
> Blit needs two basics. One bit per pixel and two bits. That is it.

No, that's not it. You could parameterise a blit close to that easy on modern
platforms with relatively uniform memory layout. Not on 8-bit home computers.

The Apple graphics modes as far as I understand stored 7 pixels per pair of
adjacent bytes _and_ the high bit shared across the pixels, to pick from an 8
colour palette with bleeding possible between pairs of pixels, while the C64
stores 4 pixels per byte, with each adjacent pair of bits representing one
pixel.

The natural implementations of those two on a 6502 is completely different.
And the bleed considerations for colours are completely different as well. But
ignoring colour, unless the guts of this is written manually for each to
minimize the umber of shifts and adds, you'll be blitting at maybe a tenth of
optimal speed if you're lucky. To add the Amiga into the mix, since it's on
the list of supported platforms.

But even for monochrome, different stride will mean a handwritten different
version will mean a _massive_ difference between platforms on a CPU like the
6502 that has no built in multiply.

You may call it a "driver", but really for a basic source to destination blit
without any operations in between, handling the bit layout and stride is
basically the entire blit function.

> Color maps and such do not need to be a part of things, or the programmer
> can manipulate them directly where they are available.

You can't do blits without taking into account the colour registers on the C64
unless you limit yourself to 4 colours (prefilling all the colour data with
the same values), because they are affected by the position of the pixel. So
either you drop down to four colours (including the background) instead of 16,
or you can't ignore colour maps. Remember we're not talking palette settings
her, but the per 4x8 pixel colour data.

So then you've basically decided to make something that will look totally
inferior to anything anyone used to a C64 expects. That's fine. But if so, why
bother targeting a C64? Nobody is going to say today "oh, this software only
works on a VIC-20, what will I do?" \- if they wan't to try it they'll just
start a VIC-20 emulator - Commodore emulators like VICE supports most of the
8-bit Commodore machines anyway.

> Your comment on the C64 Robotron is interesting. Had they broke a few rules,
> it could have delivered more like the Apple 2 did.

They didn't need to "break any rules" \- you can multiplex sprites or use
character graphics to achieve far more very easily. That is part of the point:
sticking to just the simplest means possible either looks ugly, or requires
other tradeoffs, but if you actually use the capabilities of the platform
you'd get something closer to R-Type than Robotron in terms of amount of
dynamic elements _and_ retain the gameplay. You don't need to even push the
limits to get to something far better looking and playing than the C64
Robotron port on the C64. But you do need to actually make use of the
capabilities of the platform. And bitmaps are not it.

> I was there in 85, and plenty of us played the crap out of Robotron on the
> Apple and PC

That may be a fine reason for targeting Robotron type games to Apple users
used to that quality graphics, but both Apple and PC games were laughed at by
C64 users at the time as ugly and primitive. It may well be that is a reason
for our difference in perspective - to me there's little nostalgia with games
that basic, as those were not the quality of games I remember spending time
playing as a child.

> Recently, I have been enjoying things on Apple, Spectrum, and soon maybe a
> BBC Micro. Bitmaps and clever ways of delivering the goods. I found there
> are things to appreciate, I would have not before.

That's fine. But then I'd rather see something that actually takes advantage
of the platform they're on and shows me something different, rather than
something reduced to a lowest common denominator that doesn't show off what
_any_ of those platforms actually can do.

~~~
ddingus
I challenge anyone to write a sprite multiplexer capable of Robotron! Would be
awesome to see. As for character mode, think through the cases. One arrives at
a bitmap quickly, or the movement in the game isn't really up to snuff.

Neither of these are "easy" :D

The rule breaking are things like screen tearing, ignoring color clashes,
using coarse motion where possible, etc...

>Color, differences...

At the software level, blit(x, y, etc...), the bitmap machines can handle one
and two bits per pixel. Apple has color clash in it's high bit, C64 has it in
the color cells, Spectrum has same.

That can largely be ignored.

>...Robotron type games to Apple users used to that quality graphics, but both
Apple and PC games were laughed at by C64 users at the time as ugly and
primitive.

No they weren't. We played the beautiful ones too. You are mapping your
preferences on to all of this. Nothing wrong with any of that. It's nostalgia.
We all are going to do it.

I am doing the same, and that's precisely why I said what I said. Bitmap games
are a lot of fun, have a distinct charm, and do some things that just don't
map to the higher order capabilities in these machines we love and remember
fondly.

>I would rather see...

Well, there is coding something you want to see. Standard answer there. And
neither of us even have to, as that's being done right now.

These things can / will get done too. The more the merrier man.

Re: Show off

Well, the C64 bitmap addressing is interesting. It's quick for vertical
drawing in a way the others, which generally use a linear address, sequential
byte per line scheme. I think it would have some advantages for these kinds of
projects. "show off" is an interesting term, yes?

