Steve Nickolas
2024-02-25 12:09:55 UTC
So here's what I really had in mind when I first started bringing up the
terrapin talk a couple weeks ago...
A friend of mine and I are designing a little pocket computer based on a
65C02 (I had the idea, he took it and ran with it; he's designing it at
the hardware level, but the firmware is mainly going to come from me). We
were talking about how to handle the video mode, and since he and I had
already developed one of the two working emulators for the Nabu, we wound
up deciding to just clone the Nabu's graphics chip, since we both had a
fair idea how the thing worked.
Guess what... that makes it pretty similar to a very specific
configuration of an Apple ][! Specifically, an Apple ][ with a sprite
card. That means I can do some theoretical code testing while I don't
have a workable simulation of the system, using existing resources, such
as MAME.
So...
I had in mind to try to pack as much as I could into the ROM space, which
would be somewhat larger than that of the ][ (would be 32K, actually, and
unbanked). And I was thinking, at first, the usual - you know, the kind
of stuff we have on the ][ line - monitor, miniassembler, BASIC, and we
started to think about what else might be viable, and Logo had been tossed
around as an idea. That's why I was trying to figure out how to implement
turtle graphics - because ultimately I was going to have to implement
turtle graphics on a TMS9918/65C02 pairing.
That's also going to lead to another question... Waitaminute, the TMS9918
doesn't have anything like the ]['s split screen graphics mode! Actually,
that can be fudged, with a slight limitation. G2 mode basically splits
the screen into three 256x64 windows, each implemented as a 32x8 set of
tiles. 32*8 = 256 - so often a person will just write 0-255 into each
set, then dink the font to create an all-pixels-addressable mode. In this
case, that would only be done for the first 2 blocks, then 128-255 in the
top half of the third, and a standard ASCII font loaded as 0-127 of the
third tile set. You lose the ability to do inverse text (there's still
ways to do this, by dinking the color memory), but that's still plenty
enough if you need graphics and text together. You get 256x160 graphics,
plus 32x4 text.
So testing will probably be done initially on an emulated ][ - and that
will be enough to make sure the _logic_ works.
Ultimately, I was wanting to create an environment as similar as possible
to an Apple //e, within the limits of the hardware I was targetting - and
have it, you know, a monitor, mini-assembler, BASIC and Logo - and Logo
could avail itself of the BASIC in order to implement some of its
features, they could shere their floating point library and their graphics
support (which in Logo's case would be used to implement turtle graphics).
Once I brought in graphics and Logo, though, that's where my brain melted.
(I'll probably need to do preliminary implementations in some other
language and then translate it into 65C02 postfacto, but I know nothing of
low-level handling of graphics like Bresenham algorithm, circle
algorithms, etc., and might need a hand on these things.)
The Logo implementation, if it should come to fruition, would also be
ported to the Apple since there would be practically no further effort
required.
-uso.
terrapin talk a couple weeks ago...
A friend of mine and I are designing a little pocket computer based on a
65C02 (I had the idea, he took it and ran with it; he's designing it at
the hardware level, but the firmware is mainly going to come from me). We
were talking about how to handle the video mode, and since he and I had
already developed one of the two working emulators for the Nabu, we wound
up deciding to just clone the Nabu's graphics chip, since we both had a
fair idea how the thing worked.
Guess what... that makes it pretty similar to a very specific
configuration of an Apple ][! Specifically, an Apple ][ with a sprite
card. That means I can do some theoretical code testing while I don't
have a workable simulation of the system, using existing resources, such
as MAME.
So...
I had in mind to try to pack as much as I could into the ROM space, which
would be somewhat larger than that of the ][ (would be 32K, actually, and
unbanked). And I was thinking, at first, the usual - you know, the kind
of stuff we have on the ][ line - monitor, miniassembler, BASIC, and we
started to think about what else might be viable, and Logo had been tossed
around as an idea. That's why I was trying to figure out how to implement
turtle graphics - because ultimately I was going to have to implement
turtle graphics on a TMS9918/65C02 pairing.
That's also going to lead to another question... Waitaminute, the TMS9918
doesn't have anything like the ]['s split screen graphics mode! Actually,
that can be fudged, with a slight limitation. G2 mode basically splits
the screen into three 256x64 windows, each implemented as a 32x8 set of
tiles. 32*8 = 256 - so often a person will just write 0-255 into each
set, then dink the font to create an all-pixels-addressable mode. In this
case, that would only be done for the first 2 blocks, then 128-255 in the
top half of the third, and a standard ASCII font loaded as 0-127 of the
third tile set. You lose the ability to do inverse text (there's still
ways to do this, by dinking the color memory), but that's still plenty
enough if you need graphics and text together. You get 256x160 graphics,
plus 32x4 text.
So testing will probably be done initially on an emulated ][ - and that
will be enough to make sure the _logic_ works.
Ultimately, I was wanting to create an environment as similar as possible
to an Apple //e, within the limits of the hardware I was targetting - and
have it, you know, a monitor, mini-assembler, BASIC and Logo - and Logo
could avail itself of the BASIC in order to implement some of its
features, they could shere their floating point library and their graphics
support (which in Logo's case would be used to implement turtle graphics).
Once I brought in graphics and Logo, though, that's where my brain melted.
(I'll probably need to do preliminary implementations in some other
language and then translate it into 65C02 postfacto, but I know nothing of
low-level handling of graphics like Bresenham algorithm, circle
algorithms, etc., and might need a hand on these things.)
The Logo implementation, if it should come to fruition, would also be
ported to the Apple since there would be practically no further effort
required.
-uso.