16-bit C64/128?
in [Commodore]
|
From: christianlott1 on 16 Apr 2008 03:20 ok, let me bump this thread up just a second. the building block computer mentioned a few months ago.. initially this was assumed (by me at least) to be parallel backplane bus. why not serial SPI/I2C? those real-chip/fpga modules could just be strung on a SPI bus with parallel/serial converters. i've also read about a solution for chip timing differences over the same bus that doesn't involve an arbiter per say. back in the 70s there was this thing called the Honeywell Megabus. a WRITE was one op/ cycle. a READ was two. the read was two because each chip on the bus would resolve the read request in it's own good time and the WRITE the data to the requestor when it was able. ie. a read is a write, just in the opposite direction. the article was a bit more complicated than what i'm relating because each chip had an address, but that's just memory mapping, in this case (SPI) -serial memory mapping-.
From: BruceMcF on 16 Apr 2008 08:16 On Apr 16, 3:20 am, christianlott1 <christianlo...(a)yahoo.com> wrote: > ok, let me bump this thread up just a second. > the building block computer mentioned a few months ago.. > initially this was assumed (by me at least) to be parallel backplane > bus. why not serial SPI/I2C? those real-chip/fpga modules could just > be strung on a SPI bus with parallel/serial converters. Which? It makes a difference ... SPI does not need a common bus speed, just a common ability by all devices to go as fast as the controller tries to drive them ... but without modifications, it is bus with a single bus master, multiple bus devices. For one chip to be both controller and device, it has to have multiple SPI interfaces, being the bus master on one and one of the devices on the other. I2C can arbitrate access to the common bus, but requires a common bus speed.
From: BruceMcF on 16 Apr 2008 08:22 On Apr 13, 9:55 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > On Apr 13, 7:37 pm, BruceMcF <agil...(a)netscape.net> wrote: > > On Apr 13, 7:56 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > > > With your comment about a 16 or 32 bit processor - it makes me think > > > maybe migrating these chips to a 16 bit bus board.... > > > Which is WAY off target here, so I'll stop. > > Now *that's* not Jim Brain, that's my brain (lower case b) ... > > sputtering and clattering along its same old habitual ruts. But, yes, > > if the designs work, then by the nature of the beast, they can be > > migrated to all sorts of different settings. A VIC-2020 and SID-3D in > > a CP/M system by someone with a bug to see how far the GSX can really > > be pushed. > GSX - graphic system extension? Yes, the graphic BIOS for CP/M Plus and CP/M=86 (and, either also or the precursor to, I am not sure which, GEM). > I did a little research on this a few weeks ago. It was kind of prior to the internet explosion. > All I could come up with is NCAR graphics/NCL - > http://www.ncl.ucar.edu/index.shtml > check out the gallery. I got to this by looking for GKS then DISSPLA. > The lineage seems to go from GSX to GKS to DISSPLA to NCL (I guess). > the system is downright beautiful IMO. > I don't know what kind of video adjustments you could do on the fpga > but I doubt you could come close to all that. That's a graphic library, supporting a portable graphics and data processing language, all of which seems to be over the head of the C64. But the GSX was designed with 8-bit systems in mind, and since it ran on CGA cards, in its CP/M-86 version, it seems like it would be suitable for the VIC-II display modes. > But if there was a pass thru on the daughterboard that made all the > fpga lines available a very large video system could be built up. An example of different tinkerers with different ideas, which the Chip/ FPGA system caters to. I'd want display modes that fit in the QVGA frame.
From: christianlott1 on 16 Apr 2008 11:33 On Apr 16, 7:16 am, BruceMcF <agil...(a)netscape.net> wrote: > Which? It makes a difference ... SPI does not need a common bus speed, > just a common ability by all devices to go as fast as the controller > tries to drive them ... but without modifications, it is bus with a > single bus master, multiple bus devices. For one chip to be both > controller and device, it has to have multiple SPI interfaces, being > the bus master on one and one of the devices on the other. > > I2C can arbitrate access to the common bus, but requires a common bus > speed. Then I guess it's I2C. It really makes no difference to me.The thought was first just suggested hoping someone could confirm or deny the ability of the hardware to set up a serial bus which could effectively emulate/translate the C64 parallel bus at the correct speed. On Apr 16, 7:22 am, BruceMcF <agil...(a)netscape.net> wrote: > On Apr 13, 9:55 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > > > On Apr 13, 7:37 pm, BruceMcF <agil...(a)netscape.net> wrote: > > > On Apr 13, 7:56 pm, christianlott1 <christianlo...(a)yahoo.com> wrote: > > > > With your comment about a 16 or 32 bit processor - it makes me think > > > > maybe migrating these chips to a 16 bit bus board.... > > > > Which is WAY off target here, so I'll stop. > > > Now *that's* not Jim Brain, that's my brain (lower case b) ... > > > sputtering and clattering along its same old habitual ruts. But, yes, > > > if the designs work, then by the nature of the beast, they can be > > > migrated to all sorts of different settings. A VIC-2020 and SID-3D in > > > a CP/M system by someone with a bug to see how far the GSX can really > > > be pushed. > > GSX - graphic system extension? > > Yes, the graphic BIOS for CP/M Plus and CP/M=86 (and, either also or > the precursor to, I am not sure which, GEM). > > > I did a little research on this a few weeks ago. > > It was kind of prior to the internet explosion. early 70s it looks like. it's not cpm specific. yes, GEM used it. > > All I could come up with is NCAR graphics/NCL - > >http://www.ncl.ucar.edu/index.shtml > > check out the gallery. I got to this by looking for GKS then DISSPLA. > > The lineage seems to go from GSX to GKS to DISSPLA to NCL (I guess). > > the system is downright beautiful IMO. > > I don't know what kind of video adjustments you could do on the fpga > > but I doubt you could come close to all that. > > That's a graphic library, supporting a portable graphics and data > processing language, all of which seems to be over the head of the > C64. But the GSX was designed with 8-bit systems in mind, and since it > ran on CGA cards, in its CP/M-86 version, it seems like it would be > suitable for the VIC-II display modes. you said you wanted to push GSX to the limits. this NCL _is_ GSX pushed to the limit ancestrally. > > But if there was a pass thru on the daughterboard that made all the > > fpga lines available a very large video system could be built up. > > An example of different tinkerers with different ideas, which the Chip/ > FPGA system caters to. I'd want display modes that fit in the QVGA > frame. i'm sure it can do this. source code is also available. i'd just use it right out of the box. write the NCL code, tell it to dump to a common format, translate if necessary after the image is made and send it to the (QVGA in this case) client.
From: BruceMcF on 16 Apr 2008 16:04
On Apr 16, 11:33 am, christianlott1 <christianlo...(a)yahoo.com> wrote: > > I2C can arbitrate access to the common bus, but requires a common bus > > speed. > Then I guess it's I2C. It wouldn't even be a massive undertaking to put a C64 on an I2C bus ... just get a uController that can talk SPI and I2C, and use it as a bridge. It really makes no difference to me.The thought > was first just suggested hoping someone could confirm or deny the > ability of the hardware to set up a serial bus which could effectively > emulate/translate the C64 parallel bus at the correct speed. No, it would be one of the higher speed serial buses ... I2C has a normal speed of around 100kbit/s, so it would be straightforward to support that kind of SPI/I2C bridge, even on the User Port, since the hardware CIA serial ports can go 250Kbit/s in synchronous mode. There are faster I2C bus speeds, but according to Wikipedia, it taps out at 3.4Mbit/s. And the standard address bus is 7bits ... basically, 128 device numbers. 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. > > It was kind of prior to the internet explosion. > early 70s it looks like. it's not cpm specific. yes, GEM used it. Given the time, it seems like it would be the bridge between 8bit CP/M Plus, 8086 CP/M-86, and the CP/M-68K that Atari under Tramiel originally contracted for the Atari ST (ST for Sixteen bit bus, Thirty- two bit processor). > you said you wanted to push GSX to the limits. this NCL _is_ GSX > pushed to the limit ancestrally. GSX to *its* limits, in its own right. > i'm sure it can do this. source code is also available. > i'd just use it right out of the box. write the NCL code, tell it to > dump to a common format, translate if necessary after the image is > made and send it to the (QVGA in this case) client. 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. 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. |