16-bit C64/128?
in [Commodore]
|
From: christianlott1 on 16 Apr 2008 16:40 On Apr 16, 3:04 pm, BruceMcF <agil...(a)netscape.net> wrote: > So it'd be great for a higher speed peripheral bus ... lots of > microcontroller oriented peripherals, 100kbit/s is a bus that the C64 > could keep up with, especially if there was a bridge microcontroller > in between, there'd be standard I2C support modules for the mainstream > FPGA's ... > > ... but not for a mainboard bus. so i guess that's a 'no' to my question whether the C64's internal bus could be replaced with a fast serial bus? > On what system? NCL looks like a good system, but I'd not want to use > it on anything less than a 65816, and maybe not that ... well > developed libraries often have common resource assumptions spread all > through the system, since there's no pressing need to run on a system > that cannot support the code that the module normally calls or that > normally class the module. on a PC system, using the 8 bit as client OR simply not using the full NCL capabilities - a small subset of the libraries and language. > A CP/M-86 with GSX for a CGA display, or CP/M Plus with a GSX for the > C128 VIC screen seems like something that an emulator could run, to > get an idea of what cross-platform code could be written to that API. > And having an API that was a comfortable fit for an 8-bit would be > handy if playing around with VIC-II+ display modes. A hardware implementation of common graphic functions - GSX-HW? I'd just like to see hw scrolling - and horizontal bit position addressing rather than character cell divide by eight bit map addressing.
From: christianlott1 on 16 Apr 2008 17:03 On Apr 16, 3:04 pm, BruceMcF <agil...(a)netscape.net> wrote: > A CP/M-86 with GSX for a CGA display, or CP/M Plus with a GSX for the > C128 VIC screen seems like something that an emulator could run, to > get an idea of what cross-platform code could be written to that API. > And having an API that was a comfortable fit for an 8-bit would be > handy if playing around with VIC-II+ display modes. http://en.wikipedia.org/wiki/MOS_Technology_6545
From: BruceMcF on 16 Apr 2008 18:10 On Apr 16, 4:40 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > so i guess that's a 'no' to my question whether the C64's internal bus > could be replaced with a fast serial bus? It probably could be, but I2C is not really a fast serial bus ... faster than IEC or most RS232 modems, but not fast compared to Serial ATA. > A hardware implementation of common graphic functions - GSX-HW? That would definitely speed things up for an 8-bit running free- standing. > I'd just like to see hw scrolling - and horizontal bit position > addressing rather than character cell divide by eight bit map > addressing. Yeah, I was thinking about hw scrolling. Does it have to be diagonal? Horizontal or vertical would be more straightforward. It seems that if the VIC++ is reading the bitmap in at one time, it could store that in an internal bitmap, and have a second bitmap that it starts reading on an edge, running across, to do the scroll. Given an 8 pixel border all the way around, and it can read data in a byte at a time, replacing the bitmap data that is scrolling away, and wrapping around in hardware. And yeah, it seems like it would be easier with a direct row/col pixel addressing as opposed to 8x8 character-rom addressing.
From: christianlott1 on 16 Apr 2008 21:33 On Apr 16, 5:10 pm, BruceMcF <agil...(a)netscape.net> wrote: > On Apr 16, 4:40 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > > > so i guess that's a 'no' to my question whether the C64's internal bus > > could be replaced with a fast serial bus? > > It probably could be, but I2C is not really a fast serial bus ... > faster than IEC or most RS232 modems, but not fast compared to Serial > ATA. > > > A hardware implementation of common graphic functions - GSX-HW? > > That would definitely speed things up for an 8-bit running free- > standing. > > > I'd just like to see hw scrolling - and horizontal bit position > > addressing rather than character cell divide by eight bit map > > addressing. > > Yeah, I was thinking about hw scrolling. Does it have to be diagonal? > Horizontal or vertical would be more straightforward. It seems that if > the VIC++ is reading the bitmap in at one time, it could store that in > an internal bitmap, and have a second bitmap that it starts reading on > an edge, running across, to do the scroll. Given an 8 pixel border all > the way around, and it can read data in a byte at a time, replacing > the bitmap data that is scrolling away, and wrapping around in > hardware. > > And yeah, it seems like it would be easier with a direct row/col pixel > addressing as opposed to 8x8 character-rom addressing. someone's going to need to know how big the fpga is and what type. something that will fit this vga controller maybe? http://www.opencores.org/projects.cgi/web/vga_lcd/overview
From: BruceMcF on 17 Apr 2008 07:10
On Apr 16, 9:33 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > someone's going to need to know how big the fpga is and what type. If its done, then it'll be as big as the FPGA in the chip-fpga board is, and that type. I guess its now time for the Xilinx vs Altera pie fight, but I'm on the sidelines. |