From Newsgroup: comp.sys.cbm
Matthew Montchalin <
mmontcha@OregonVOS.net> wrote in news:
Pine.LNX.4.44.0307072340050.3764-100000@lab.oregonvos.net:
It's extensive rather than exhaustive.
At the same time exhausting for the typist.
No, it's been like that for the rest of us since you and your horse
first got here.
Yeah, and you annoyed everyone here too.
No, just straight-faced lack of confidence in your abilities to
describe the thing from the hardware up, certainly total incredulity
when it comes to your ability to describe the mapping of the DMA
engine to memory.
Matthew, it I was given all the tentative documents that are not being distributed to anyone even you. I would not have that kind of info. First
off, hardware chips are often have one or more mappable locations.
Hardware is instantly mapped. Old ISA boards are very similiar (yet have
there differences) to CBM hardware devices. They have a series of jumpers
on board so you can manually configure the cards mapped locations as
mapping is instant as that is where in memory the main microcontroller's registers woulds be mirrored to. Since these hardware from time to time
share the same main memory as with the CPU. There is times when the CPU
has to just sit and wait. Ok. Simple as that. Some hardware can be
dynamically loaded depending on which devices are mapped in which
locations. For the most part, hardware can not share the same location.
They can share the same IRQs if IRQ sharing is an option. Yet this is
mostly found in Windows/Linux PC hardware. This will make sense with PCI.
Now, DMA simply means Direct Memory Access. Turn the Fucking CPU Off and
take control of main memory. Ok, with the C-One, I would say that you
would put the CPU on stand by and take control of the SD-RAM Controller
and have control of the operations from the SuperVIC core. I would assume
that will be all internal inside one of the FPGAs. I can not answer that question 100% because the info in the terms of the C-One is not that
highly documented or at least published.
Let's go for the basics of her graphics board.
I will only be able to provide information that is documented - um
released.
|Jeri is developing a "coreset" to make the FPGAs functions like chipset >|used by a given computer model that you select.
The 65816 'native' mode. The one with a fantastic new graphics board,
and DMA memory manager.
I will give you more information as the board is released. As stated,
some documentations will be released as the C-One is released. This is preventing documentations going out and having to rewrite and reprint documentations that are obsolete and inaccurate.
|If you select a C64 mode to boot into.
Oh, I could turn a real C-64 on, if that's all I wanted.
Yes... That is exactly the key to the menu program and loading the of the
FPGA with the appropriate binaries and loading the ROMs. The FPGA uses a dynamic mapping model.
The principle is that an average user (dumb orc) can simply press the key
for the mode he or she wishes to boot in and in a flash - the screen
should show the mode he or she wishes to be in. Say I pressed the "1" key
for C64 mode, I should expect the famous c64 prompt showing with the
flashing cursor and then type LOAD"*",8,1 and then type RUN and my
favorite 5.25" C= Game should execute as usual. That is the quality that
we want. I should expect my GUNSHIP game to start up with its famous
tune. As well as one of my favorites "ACE2" start up and be listening to
the famous Rob Hubbard tune. These are the games that really got me into computers.
As far as an OS correlating to the hardware, one could map the hardware
and update an integrated database to hold the data so an application can
go off a central data information source and not be stuck with hard coded memory access to explicit memory location. Hard coded memory access from applications can be a bad thing in an environment in which hardware is
dynamic and the key is to keep the application level software away from physical memory until it has gathered current and correct information and
that all hardware modifications or updates are done through OS routines
which will automatically update the OS's integrated database system. This
will then give an application a fairly decent source for the current information where hardware would be mapped before the app writes or reads
from the memory. You certainly do not want the app to be writing wherever
the app programmer decides as that may not be correct from one persons configuration to another. That is why Hardware IDs may be given as keys
for use of associated arrays. Say an Associative Array of Registers.
Simply search the RegisterMappingArray for SD-RAM_BANKSWITCH and you
should be able to retrieve a hexadecimal value of the register. This is a little idea behind my OS. Hardware will likely be mapped as the computer starts and the OS starts but I need to be open to handle "real-time"
changes.
There are several ways to handle this.
|We essentially load the C64 chipset into the C-One.
Nah, tell me about the 65816 'native' mode instead.
Ok, which part do you want to start with. I am only able to go with the
same info that you were given too like everyone else.
|This is done by loading in a set of files into the FPGA.
Assuming Per Olofsson's code worked.
Yes, assuming it works.
(From the last time I checked, it seems to be working at least from the screenshots)
|This set of files can be called a "coreset". You can not map hardware
|until you know what you chipset is going to be and that is determined
|by the "coreset" files.
Rather, the core had damn better support the signals for the pins
of the 65816, where they OUGHT to be, or it aint gonna work AT ALL.
Think about that, Rick, and let it sink in, if you can.
Yes... That is why different coresets maybe used for use with different
CPUs. I understand that. The same rules go for a z80 as well as any other
CPU. Otherwise, you could possible damage your CPU if it was not done
right. We are talking about hardware and basic electronics. So let's
always keep that in mind.
I don't care; I will be plugging a real 65816 in, anyway. No need
for Gideon's quasi-65802. If you aren't going to let us plug a
real microprocessor in, then why even have a universal 'socket?'
The 65c816 is stock anyway so you really just need to get the machine as
is. You do not really need to use the CPU Slot unless you want a fancy
CPU Slot that also gives you z80 as well and gives you some method to
handle switching between the two CPUs for stuff like C-128 stuff and CP/M stuff. And we get down to working out a Super-VDC.
<worthless blather snipped>
|The C-One is very different.
Really? In what way?
IBM PCs are static hardware accept for the mapping process.
--- Synchronet 3.18b-Win32 NewsLink 1.113