Floppy Partionning system

All discussions related to the DCPU and in game hardware (equipment, vehicles)

Re: Floppy Partionning system

Postby Zardoz » Mon Nov 25, 2013 8:56 pm

S0lll0s wrote:
Zardoz wrote:The BIOS can't be load from a disk !!! The BIOS is a little program that is burned in a ROM chip, can't be updated or uploaded. If you like to replace it, you must replace the entire chip.

Yeah, and I propose that the BIOS is on a ROM chip that can be flashed (like any IRL chip) using a lot of cost

You mean that the BIOS being a EEPROM allowing to upgrade (or overwrite and replaced by malicious software). Could be... I personally like more of flashing the chip with the computer power off, like if were unpluged put in a EEPROM burner, rewrite and pluged in the machine..

S0lll0s wrote:And instead of expanding the DCPU spec unreasonably (i.e. by introducing a PC that does not point to the memory) I suggest that instead of executing the ROM "directly" it is copied into the beginning of the RAM on poweron and then executed just like anything else.
If this was not the case we would need an extra instruction (or at least an extra flag) to tell the DCPU to switch to "regular memory" when the BIOS is done.

It is called "Shadow BIOS" in some old PCs. It was speed-up trick because these ROM/EPROM of these time was too slow compared to the CPU bus, and copying ROM data to RAM allow to speed up software that needs to use the BIOS routines. In our case this speed-up is unnecessary. The only reason that I can find to be necessary, is in the case of the DCPU-16 as a alternative to bank switching. as allow to reuse these space address. But in the case of the RC3200 not have any sense... you have a lot of address space.

You not need "extra instruction" to handle ROM. Simply, a range of address are Write only. This means that if a computer program try to write at these address, nothing will happen. This you could see in RC3200-VM were you have a 64KiB ROM + 128KiB RAM, and if you try to write over the 64KiB ROM, simply does nothing, like in a real machine.
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

Re: Floppy Partionning system

Postby VladVP » Tue Nov 26, 2013 10:33 am

S0lll0s wrote:
Zardoz wrote:The BIOS can't be load from a disk !!! The BIOS is a little program that is burned in a ROM chip, can't be updated or uploaded. If you like to replace it, you must replace the entire chip.

Yeah, and I propose that the BIOS is on a ROM chip that can be flashed (like any IRL chip) using a lot of cost. And instead of expanding the DCPU spec unreasonably (i.e. by introducing a PC that does not point to the memory) I suggest that instead of executing the ROM "directly" it is copied into the beginning of the RAM on poweron and then executed just like anything else.
If this was not the case we would need an extra instruction (or at least an extra flag) to tell the DCPU to switch to "regular memory" when the BIOS is done.

Why do we need an additional PC register to execute the ROM? Why do we need an entire flag to execute the ROM? The ROM is usually around address space A000h-D000h. We just have to initialise PC to the beginning of the ROM.
VladVP
 
Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

Re: Floppy Partionning system

Postby S0lll0s » Tue Nov 26, 2013 8:15 pm

Zardoz wrote:
S0lll0s wrote:
Zardoz wrote:The BIOS can't be load from a disk !!! The BIOS is a little program that is burned in a ROM chip, can't be updated or uploaded. If you like to replace it, you must replace the entire chip.

Yeah, and I propose that the BIOS is on a ROM chip that can be flashed (like any IRL chip) using a lot of cost

You mean that the BIOS being a EEPROM allowing to upgrade (or overwrite and replaced by malicious software). Could be... I personally like more of flashing the chip with the computer power off, like if were unpluged put in a EEPROM burner, rewrite and pluged in the machine..

That's what I meant by cost: it takes time and resources.

VladVP wrote:Why do we need an additional PC register to execute the ROM? Why do we need an entire flag to execute the ROM? The ROM is usually around address space A000h-D000h. We just have to initialise PC to the beginning of the ROM.


That would waste address space that is (probably) only used once. 3000h words is a lot and could be used for dynamic memory.
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Floppy Partionning system

Postby VladVP » Tue Nov 26, 2013 9:55 pm

S0lll0s wrote:That would waste address space that is (probably) only used once. 3000h words is a lot and could be used for dynamic memory.

Well, nothing to do about that, mayte! The ROM is as big as the ROM is. You can't just make it smaller. Also, the ROM is unlikely to be 24 KB, (I did say around) but even if it was, there would stilll be 128 KB of addressing space in total, and that's just on a disk with 16-bit word-referencing addresses.
VladVP
 
Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

Re: Floppy Partionning system

Postby Zardoz » Tue Nov 26, 2013 11:21 pm

S0lll0s wrote:That would waste address space that is (probably) only used once. 3000h words is a lot and could be used for dynamic memory.

It's false. Usually the BIOS not only stores a bootstrap code, also stores some useful and very recurrent functions, like "print" to the screen, etc...

For example, the original Apple II had a 8 KiB ROM that included a BASIC interpreter... Without the interpreter probably will be half or less.

PD: You are assuming that we will use the DCPU-16 when this is not clear. For what I know, we can end using the LUA OS thing or any other thing.
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

Re: Floppy Partionning system

Postby S0lll0s » Wed Nov 27, 2013 5:36 pm

Zardoz wrote:
S0lll0s wrote:That would waste address space that is (probably) only used once. 3000h words is a lot and could be used for dynamic memory.

It's false. Usually the BIOS not only stores a bootstrap code, also stores some useful and very recurrent functions, like "print" to the screen, etc...

For example, the original Apple II had a 8 KiB ROM that included a BASIC interpreter... Without the interpreter probably will be half or less.

PD: You are assuming that we will use the DCPU-16 when this is not clear. For what I know, we can end using the LUA OS thing or any other thing.

Then we can close this whole thread and any others in the hardware forum too (except for new CPU proposals).
IMO Trillek has some kind of responsibility towards the DCPU-16-community (at least if it continues to be a "replacement 0x10c").
A LUA OS just doesn't cut it, I can go play gmod as well then. The only really innovative thing in 0x10c and Trillek have always been the low-level-programmable computers, and it's the only thing that really interests me in this project.

Also, that still doesn't justify the waste of the bootstrap code inside the BIOS. I really don't see any advantages of your ROM-in-memory over a chip that is copied into memory on poweron.

VladVP wrote:
S0lll0s wrote:That would waste address space that is (probably) only used once. 3000h words is a lot and could be used for dynamic memory.

Well, nothing to do about that, mayte! The ROM is as big as the ROM is. You can't just make it smaller. Also, the ROM is unlikely to be 24 KB, (I did say around) but even if it was, there would stilll be 128 KB of addressing space in total, and that's just on a disk with 16-bit word-referencing addresses.

Yes you can make it smaller, by making it writable / creating a writable copy in memory.
And thats my whole point - it saves space.

Also if there are routines like print-to-screen in the ROM, then obviously the OS should use them. This would mean that you'd have to standardize the ROM routines so you can run different OS' without having to flash your BIOS every time (which partially defeats the purpose of an OS).
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Floppy Partionning system

Postby Zardoz » Wed Nov 27, 2013 11:25 pm

S0lll0s wrote:Then we can close this whole thread and any others in the hardware forum too (except for new CPU proposals).
IMO Trillek has some kind of responsibility towards the DCPU-16-community (at least if it continues to be a "replacement 0x10c").
A LUA OS just doesn't cut it, I can go play gmod as well then. The only really innovative thing in 0x10c and Trillek have always been the low-level-programmable computers, and it's the only thing that really interests me in this project.

I think like you. The thing that attracted me to 0x10C and Trillek is the low-level-programmable computers and the idea of building the computer from a mother board and some devices attached to it. I always defend using a simulated CPU vs LUA OS (or similar). But I recognize that LUA OS will be more practical.

We can keep this and other discussion but trying to be more generic and not concrete about a particular CPU.

S0lll0s wrote:Also, that still doesn't justify the waste of the bootstrap code inside the BIOS. I really don't see any advantages of your ROM-in-memory over a chip that is copied into memory on poweron.


The bootstrap is necessary because the CPU will not use magic to load things from a floppy or hard disk. Plus having some BIOS with some minimal stuff, allow to use it without a floppy/hard disk.

S0lll0s wrote:Yes you can make it smaller, by making it writable / creating a writable copy in memory.
And thats my whole point - it saves space.


I said before that is a underpowered but acceptable alternative to bank switching for 16 bit CPUs. 32 bit CPUs not have any problem with address space.

S0lll0s wrote:Also if there are routines like print-to-screen in the ROM, then obviously the OS should use them. This would mean that you'd have to standardize the ROM routines so you can run different OS' without having to flash your BIOS every time (which partially defeats the purpose of an OS).


Yes, it's obvious that the ROM contains and functions must be standardized. This is another reason to not allow a easy and straightforward way of overwrite the ROM except as a update (always will be bugs). And not, this not partially defeats the purpose of a OS. Usually this common low level functions are using by the OS loading process like accessing the hard disk, printing boot info, etc... Later the OS can use it or not, but they are here as fall-back.

The BIOS could be of this kind :
    1) bootstrap code : pretty minimal 512 octets or less of possible size
    2) bootstrap + some basic useful I/O routines that allow a program or a basic OS to work. -> around of 1KiB to 4KiB ?
    3) bootstrap + some basic useful I/O routines + BASIC (or other easy language) interpreter -> from 4 KiB to 32 KiB
    4) bootstrap + some basic OS like Amiga Kickstarter ROM -> 32 KiB or more
This can be spiced with things like a integrated assembly monitor (Apple II or Apple I had it, not ??), or other stuff... Take a look to the old 8 and 16 bit computers of the 80's.

I'm pro 2 and 3 BIOS kind.
Yep, I have a blog : http://zardoz.es
Emulator DCPU-16 VM
User avatar
Zardoz
 
Posts: 359
Joined: Mon Aug 12, 2013 8:54 pm
Location: Spain

Re: Floppy Partionning system

Postby VladVP » Thu Nov 28, 2013 5:33 pm

S0lll0s wrote:Yes you can make it smaller, by making it writable / creating a writable copy in memory.
And thats my whole point - it saves space.

What are you talking about? How are you going to access the ROM if you don't have a set of addresses pointing to it?
VladVP
 
Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

Re: Floppy Partionning system

Postby S0lll0s » Thu Nov 28, 2013 10:56 pm

VladVP wrote:
S0lll0s wrote:Yes you can make it smaller, by making it writable / creating a writable copy in memory.
And thats my whole point - it saves space.

What are you talking about? How are you going to access the ROM if you don't have a set of addresses pointing to it?

-.-.-.-.-.-.-.-.-.-.-
as i am now mentioning for the 4th time by copying the ROM into the standard RAM address space where it is writeable.


also @Zardox: You still didn't give any advantages of your system.
Yeah, Apple I and Apple II did it, so what? We don't need to do this if we just want to copy an existing arch and system.
S0lll0s
 
Posts: 58
Joined: Fri Sep 20, 2013 9:13 pm

Re: Floppy Partionning system

Postby VladVP » Fri Nov 29, 2013 8:35 am

S0lll0s wrote:
VladVP wrote:
S0lll0s wrote:Yes you can make it smaller, by making it writable / creating a writable copy in memory.
And thats my whole point - it saves space.

What are you talking about? How are you going to access the ROM if you don't have a set of addresses pointing to it?

-.-.-.-.-.-.-.-.-.-.-
as i am now mentioning for the 4th time by copying the ROM into the standard RAM address space where it is writeable.


I don't even have words to describe how horrendous of an idea that is.
Despite the fact that you probably aren't going to use the ROM, it is absolutely vital to be able to access it. Merely copying data from an isolated memory device will in the end just make the computer slower to boot up and use more resources than the traditional approach(es).
VladVP
 
Posts: 95
Joined: Fri Nov 01, 2013 8:31 pm

Previous

Return to Hardware

Who is online

Users browsing this forum: No registered users and 2 guests