C128 questions [Commodore]

Prev: 1581 Drive Kits on eBay
Next: Wireless internet!

From: a7yvm109gf5d1 on 27 Jul 2006 14:58

Hi,
What are the most common devices found on the user port of the 128? I'm
trying to compile a list of devices, and hopefully find their
schematics, so I can figure out which is the best way to use 4 output
bits transparently.

I'm going to be connecting 4 bits to the unused inputs of the scan
converter chip, so it would be possible to select from 16
color-constrained palettes on the fly. This could give the up-converted
output up to 256 colors out of 16M since the LUT outputs are 8 bits.

I'd also need 2 bits free to program the LUT from the 128, or at the
very least the TXD line so you can talk to the converter's
microcontroller.

Of course, syncing the code to the VDC is something I know nothing
about. I'm pretty sure it's possible to at least change the palette on
a character line basis.

No Rick, you won't be able to select palettes on a pixel by pixel
basis. :)

I don't even have the PCB yet, and I'm already thinking of the next
version. So much for not succumbing to featuritis.

From: Rick Balkins on 27 Jul 2006 18:13

<a7yvm109gf5d1(a)netzero.com> wrote in message
news:1154026682.913031.257680(a)h48g2000cwc.googlegroups.com...
> Hi,
> What are the most common devices found on the user port of the 128? I'm
> trying to compile a list of devices, and hopefully find their
> schematics, so I can figure out which is the best way to use 4 output
> bits transparently.

300-2400 baud modems. However, most of us are using faster modems and can
live with disconnecting a typical modem like the Commodore modems and the
Aprotek modems.

> I'm going to be connecting 4 bits to the unused inputs of the scan
> converter chip, so it would be possible to select from 16
> color-constrained palettes on the fly. This could give the up-converted
> output up to 256 colors out of 16M since the LUT outputs are 8 bits.
>
> I'd also need 2 bits free to program the LUT from the 128, or at the
> very least the TXD line so you can talk to the converter's
> microcontroller.
>
> Of course, syncing the code to the VDC is something I know nothing
> about. I'm pretty sure it's possible to at least change the palette on
> a character line basis.

Character line basis or character cell basis. Either way, sounds good. Just
being able to change pallettes multiple times on the screen is an
improvement to the VDC function. I wonder if MMU can be kicked into play
here.

> No Rick, you won't be able to select palettes on a pixel by pixel
> basis. :)

It doesn't have to be. Maybe on the character cell by cell basis or
whatever. Depending on speed of routines and what not. I expected pixel by
pixel to be a little challenging on 1 MHz or even 2 MHz cpu. Easier, syncing
with char clock which is 2 MHz and most any of the I/Os can do that. Of
course, I'm looking at least multiple times on the screen. The faster the
routines, and more updates per frame, the more can be seen on screen at
once. Pixel by Pixel was the 'ultimate' ideal condition but I'd expected
that without some (20 Mhz) I/O and CPU, it would be a little bit too
challenging to achieve to that level.

So updating LUTs (say 2000 times) vs. 128,000 times is more realistic.
Updating it 1000 times is realistic. However, with VDC FLI techniques like
done by Graham of Oxyron and a little bit of room can possibly be done
(without running say the SID), I think being able to achieve a character by
character basis is realistic. This can give us opportunity to update
pallette on a cell by cell basic - which is probably more than reasonable
for anyone with a C-128/128D.

Giving room for some very nice effects - even if not pixel by pixel. I do
have the reasonable option to sync with chars within the VDC.

Even with normal VDC hires bitmapping, nice looking images can be displayed
with the benefit of updating the LUTs. By doing what is said and clever
pixel artistry,code timing, we can see nifty image work.

I'd look forward to hearing from you some more. I didn't 'expect' pixel by
pixel with the 128 bus but expect possible character by character or even by
2-4 characters at a time and update once every 2-4 characters (500-1000
times per screen drawing.)

If this is reasonable, we got something nifty and either way, the VDC is
being improved (externally). Either way, it is an improvement - since the
VDC will still be able to do anything it already does but can be augmented
externally.

In normal hires, we would have 2 colors per char cell. Using VDC FLI
techniques and dropping any usage of SID to produce sound (freeing clock
cycles), we could achieve the usage of 16 colors per cell. By modifying the
LUTs on a per character basis, we could in theory have a new pallete of
colors to work with and have 'on-screen' - a theoretical usage of 32,000
distinct colors out of the 16 Million color pallette within the same image -
without using 'dithering' which is not really producing a true new color.
These would be 32,000 distinct 'non-dithered' colors within a given image.

In normal hires mapping, you would in theory be able to display on screen
within the whole image 4000 distinct colors with normal attribute cell
limitations.

Of course in VDC FLI, you would have only 2 colors per 8x1 group of pixels.

In normal hires, you would have only an option of 2 colors per 8x8 pixel.

I'm simply looking at being able to change pallete - say once every 1-4
characters at least. A nice feat and interesting potential.

In short, sync with chars is easier because we can find that information out
in the registers pretty quick and we just need to play fast enough. ML is
the key, here. Mainly you be working with $d600 & $d601. I have a C-128 PRG
in a PDF file.

> I don't even have the PCB yet, and I'm already thinking of the next
> version. So much for not succumbing to featuritis.
>

Just don't succumb too much in featuritis.

Ultimately, I'd look forward to seeing what this thing can do and ultimately
test our options. To me, it is being able to change the pallete multiple
times that matters, not how many times. That, we can explore in practice and
try different routines to see what does what.

From: Rick Balkins on 27 Jul 2006 18:31

Almost forgot, there was a IEEE-488 interface that plugged into the User
Port.

Although, this was made back in the early C64 days. It would be runnable on
the same 128's User's Port but the IEEE drives were 1 Mhz and that would not
run well in 2 Mhz mode. The main difference is that the C-128 User's Port
would run in 2 Mhz mode because of the 8522s or was that 8526s. The I/O
chips did run in 2 Mhz mode and can sen data in a parallel bus like fashion
in 2 Mhz mode, IIRC.

Don't use UART mode.... slow - modem emulation. Use parallel bus mode if
possible.

From: Rick Balkins on 27 Jul 2006 19:10

"Rick Balkins" <nospam.rickbalkins(a)nospam.wavestarinteractive.com> wrote in
message news:b9byg.3718$db.3539(a)fe03.lga...
> Almost forgot, there was a IEEE-488 interface that plugged into the User
> Port.
>
> Although, this was made back in the early C64 days. It would be runnable
> on the same 128's User's Port but the IEEE drives were 1 Mhz and that
> would not

I'm double-checking this info. However there are various parallel interface
modules that uses the User's Port such as the Centronic ones.

> run well in 2 Mhz mode. The main difference is that the C-128 User's Port
> would run in 2 Mhz mode because of the 8522s or was that 8526s. The I/O
> chips did run in 2 Mhz mode and can sen data in a parallel bus like
> fashion in 2 Mhz mode, IIRC.

I stand corrected from the 128 PRG - they are 6526s. 1 MHz.

However, I'll have to look into the MMU and whatnots.

> Don't use UART mode.... slow - modem emulation. Use parallel bus mode if
> possible.

However, I still recommend, parallel mode over the UART emulation (RS232
mode). Faster data rate. I'll have to see check more specific detail.
However, I'd likely can expect LUT updates - once every say - 8-16 chars.

From other conversations, I'd suspect 125K top data rate transfer. Giving
8cyc per byte. Transfering of 768bytes per LUT update. Means about 162-163
times per second. This would probably equate to once every 13 character
cells. This is still nice to see. Likely, once every 16 chars - 125 times
per second.

I don't know about how the MMU comes to play on the User Port or if it does
at all.

From: Rick Balkins on 27 Jul 2006 21:47

|
Pages: 1
Prev: 1581 Drive Kits on eBay
Next: Wireless internet!