Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Hollywood MAL AMIStore App Store A600 Memory

AuthorTopic: Os 3.2 development preview  (Read 20715 times)

0 Members and 3 Guests are viewing this topic.

Online TribbleSmasher

Re: Os 3.2 development preview
« Reply #120 on: September 19, 2019, 03:25:42 PM »
Yes, but the latter only holds 232 Bytes with limited information and not in a flexible format. While now one could bundle several chunks of all kinds together, making even different combinations of setups easily manageable.
 

Offline SamuraiCrow

Re: Os 3.2 development preview
« Reply #121 on: September 19, 2019, 05:39:39 PM »
MrgCop() and it's macros do not expose sufficient capabilities on AGA or earlier so the OS routines should not be used by anyone trying to target such systems.
I'm not quite sure which capabilities this should be. The copper writes a value into a register - that's really it, it did not become more capable on AGA.

However, this aside, the problem is not even MrgCop(). The problem is that the system creates copperlists in one way, and then has a couple of extra functions that "poke" on the created copperlists, bypassing the regular copper list creation functions. This is particularly tricky for the copper "wait" functions as several (hardware) copper instructions need to be combined to make up a wait for an arbitrary position. Unfortunately, these "other" functions expect for that a particular form of the copper lists.

So we have two (actually even three) sets of functions that operate on the copper lists. Partially in C, partially in assembler. One abstract "copper list built-up function" aka MrgCop(), to which CMove and CWait() also belong, and the SetColorMapXX() functions (poke directly into the copper list) and the VideoControl functions, which also directly poke into the existing copper lists - both bypassing the abstraction layer. Changing one makes another one explode in your face.

As a side remark, Os 3.1 had exactly in this mess a bug: If you had a productivity screen and a workbench hi-res screen, and a 35ns sprite on the productivity screen, and a 70ns sprite on the workbench, and you closed the productivity screen, graphics would have scrambled your memory. The sprite size adjustment tried to "poke" an already existing copper list (instead of using the proper abstraction), but the copper list it referred to belonged to the screen that was just being closed, and thus was already released memory.

The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.

This allows the "infinite vertical scroll wraparound" that uses the modulo register to make the bitplane pointers all jump to the top of the buffer when the end is reached with a negative signed addition and then reverts the modulo register the next rendered row of pixels.  It's only 2 waits and 2 moves but they aren't always in the same order when you do it on both playfields.
 

Online TribbleSmasher

Re: Os 3.2 development preview
« Reply #122 on: September 19, 2019, 09:33:26 PM »
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x
Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #123 on: September 19, 2019, 10:30:43 PM »
The biggest problem with MrgCop and its macros and support functions is that it doesn't and cannot sort blocks into the order that they are supposed to go in.  If you are using dual-playfield mode and color changes for the sprites, for example, trying to get all the copper instructions to line up with both playfields and 8 other moving objects requires sorting, not just merging.  One hardware banging engine written in C uses a "blocks mode" where the first instruction in a block is a copper wait and all additional copper move instructions are after it in a form that resembles Chomsky Normal Form.  This allows all the blocks of copper instructions to be properly sorted with minimal overhead.
I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.

Offline Matt_H

Re: Os 3.2 development preview
« Reply #124 on: September 20, 2019, 02:13:19 AM »
Not sure where feature requests go, but if 3.2+ could have an update to scsi.device to natively support the 4-way IDE adaptors on the 4000/1200's rather than using the old IDEFix hack, that would be neat!
No - why? Did IDEFix stop working in 3.1.4?

No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
 

Offline SamuraiCrow

Re: Os 3.2 development preview
« Reply #125 on: September 20, 2019, 02:33:17 AM »
I'm sorry, but I'm not sure what you want to tell. CMove and CWait both go into the user copper list, and MrgCop() does not change the order of instructions on this list. What it does is that it merges the (abstract) user copper list, the (abstract) copper list of the VSprite system and the (abstract) copper list of the view port arrangement into one hardware list. As long as there is a single VPort, it does not matter whether it runs in dual playfield mode or not.

Thus, while you cannot guarantee the relative order of the user copper list relative to the vsprite copper list, the relative order of instructions within each list is stable.
The main problem with the current abstraction is that it stores one virtual instruction per "block" and CBump() moves immediately to the next instruction which prevents grouping of related instructions.  A wait followed by a variable number of moves should be treated as a single "block" of memory so they can be sorted into the order needed regardless of the position being waited for at the beginning.

The ACE (Amiga C Engine) source is available as open-source on GitHub.  I should check the licence and make a Chipset.library to replace Graphics.library on systems that need chipset support.
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #126 on: September 20, 2019, 05:48:09 AM »
No, but it's a hack originally created to work around a limitation in the OS at a time when the OS was out of development. Similarly, atapi.device from the same package was necessary because the IDE scsi.device didn't know how to handle CD drives. With the OS back in development, my understanding is that the latter issue has been solved and atapi.device is now redundant. The former should be made redundant at some point in the future as well. Granted, it's a low priority given that IDEfix "works," but at some point it really should go.
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation. Why is it a limitation of the Os when it does not support such proprietary extensions from third party?

Offline kolla

Re: Os 3.2 development preview
« Reply #127 on: September 20, 2019, 08:51:33 AM »
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x
Actually, this is not the same.
WB1.x has only one Prefs editor (I think pointerprefs is just merged in or so) . OSX and MOS have several separate editors, called Panes (OSX) that are loaded when clicked.
Right, those of macOS and MorphOS are modular (and if I recall correctly, due to nature of MUI, the MorphOS Prefs modules can even be launched individually). It's just one of many, many things that MorphOS has done much more elegantly than anyone else, and with help of Zune, AROS could do the same.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline kolla

Re: Os 3.2 development preview
« Reply #128 on: September 20, 2019, 09:06:30 AM »
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.
Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.
Quote
Why is it a limitation of the Os when it does not support such proprietary extensions from third party?
Because it's not proprietary? Anyone can twist around IDE cables and add connectors. In addition, there are implementations of Minimig that support this "out-of-the-box" and let you use 4 disk images at once.

http://aminet.net/package/docs/hard/4IDE
« Last Edit: September 20, 2019, 09:11:28 AM by kolla »
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
 

Offline Pgovotsos

Re: Os 3.2 development preview
« Reply #129 on: September 20, 2019, 06:03:09 PM »
Sorry, but I'm confused. The original Amiga hardware supports one IDE channel, thus two devices (master, slave). The four-way adapters are to my knowledge proprietary extensions that require a hardware installation.
Not much hardware, strictly speaking, only a custom cable is required. However, buffering is preferred so typically a small board is used, that both splits the IDE signals and add buffers.
Quote
Why is it a limitation of the Os when it does not support such proprietary extensions from third party?


To connect 4 IDE devices, you DO need the additional hardware to add support for another IDE channel. No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.
 

Offline paul1981

Re: Os 3.2 development preview
« Reply #130 on: September 20, 2019, 08:13:29 PM »
Or maybe an all-in-one Prefs-Launcher similar to the Mac OSX one, or MorphOS, same kind.
Or OS 1.x

Quote
I remember a 'Registry'-style preferences tool back in the days, dunno, if this was ever considered to be adapted. 'Registry' meaning all prefs' IFF chunks in one big prefs file together.
Also on OS 1.x, DEVS:system-configuration (if I remember correctly).

Note that one can still run old OS 1.x "Preferences" under OS 3.x and DEVS:system-configuration is still read on boot, even when booting without startup-sequence - I use it to set a different "deault" palette than the white/black/grey/blue of OS2 and 3.

Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.

Failing that, there is always Jonathan Potter's 'Preferable Preferences' aka PPrefs on fish disk 242, which is a direct replacement:

http://aminet.net/package/misc/fish/fish-0242

Offline psxphill

Re: Os 3.2 development preview
« Reply #131 on: September 20, 2019, 09:35:00 PM »
To connect 4 IDE devices, you DO need the additional hardware to add support for another IDE channel. No playing with cables alone is going to allow you to connect more than two devices. The internal IDE controllers can only handle one IDE channel without hardware to add logic for a second IDE channel, thus only two devices on stock IDE controller period.

The Aminet link you provided is for just this sort of hardware. It's not for any cable shenanigans.

Actually the additional hardware is mostly for buffering, which allows it to go quicker somehow (if someone who understands how that works could explain then I'd appreciate it)

But getting 4 drives instead of 2 is very simple. ATA works very much like ISA, it's like a standard cpu bus. Each hard drive has 16 addresses allocated to it, but it's really only the first 8 that are really used.

Helpfully there is a separate pin that tells the drive whether the computer is accessing the first block of 8 or the second. If you feed each of those to the first block input of both drives, you can talk to 4 drives instead of 2. Essentially when you access the second block of registers of drive 0, you're actually accessing the first block of registers of drive 2.

From the standard: http://www.t13.org/documents/UploadedDocuments/project/d0791r4c-ATA-1.pdf

It's these

| HOST CHIP SELECT 0 37 | ----- CS1FX- -------->| 37 |
| HOST CHIP SELECT 1 38 | ----- CS3FX- -------->| 38 |

The second block of registers is actually quite sparse, by not being able to access the second block you lose three things
1. being able to soft reset the drive
2. being able to disable the irq generation
3. being able to read the "alternate status", which just returns the normal status without clearing any pending irq.

I'm not sure if the original scsi.device even relies on these in the first place & you can probably gate the irq further up (in gayle or intena). Not sure whether you can control the reset line of the ata bus using gayle (I have a vague recollection that cutting that was necessary for some drives anyway).

That is what the hacked cable in the aminet package does, it should work fine with the atapifix software. It would be great if scsi.device could be extended to support it, it would probably be very trivial. You'd want to come up with a detection for it, I think you could probably do it quite easily by trying to access a register in the second block that doesn't exist but is read/write in the first block.

Looking at "7.2 I/O register descriptions"

sector count would be a good one for detection.

CS3FX- (Control block registers)

| 0 | x | X | Data bus high imped | Not used |

CS1FX- (Command block registers)

| 0 | 1 | 0 | Sector count | Sector count |

(the two CS registers are active low)

I think the amiga linux distributions support it, so it's probably worth reading how they do it (aros 68k may also support it, I haven't looked at that code in years though)
« Last Edit: September 20, 2019, 10:19:24 PM by psxphill »
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #132 on: September 21, 2019, 02:52:01 AM »
Yes, it would be handy if the 1.3 prefs editor was included, being as though the system-configuration file has always been supported even up to 3.x. It could be thrown in the Prefs drawer or Tools drawer with no icon, to make it kind of a hidden tool.
The preferences system changed quite a bit from 1.3 to 2.x style, so a 1.3 prefs editor is not sufficient. Unfortunately, the overall logic is not very canonical. There are preferences intuition wants to learn over the old-style prefs system, but some are installed by additional intuition calls, like those for the input control. For the printer.device, unit #0 takes the prefs from system-configuration, but all other units from dedicated prefs files which are parsed by the printer.device directly.

Offline asymetrix

Re: Os 3.2 development preview
« Reply #133 on: September 21, 2019, 03:00:21 AM »

Even TODAY there are angry theme makers for other platforms because they cannot keep a compatible and easy system for people who enjoy making themes.

Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
History *could* be a cli version of installer - simulate/test/undo/redo commands, then comit changes.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.

virtual-path = URI
One could have virtual paths EG Workbench:virtual-path\test


Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.

The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries

At times I select a file and hit DEL expecting it to just delete. lol.

Unique ideas make for interesting and exciting times.
 

Offline Thomas Richter

Re: Os 3.2 development preview
« Reply #134 on: September 21, 2019, 03:23:24 AM »
Is shell History a text list or is it a workflow automation/virtual environment session eg Vagrant ?
It is first and foremost a command that lists the history whose output you can process by Shell tools. The implementation is that of an exec-style doubly linked list. There are currently no other tools around the history.

Could the soft-links work for example in a large project with all same header files all using soft-link to *one*, so
change *any* header (.h) changes all of them? - that would be nice to have.
Softlinks are soft-links, you can use them as you like.

Does 'replacing ROM components' mean replacing class/data structures, or like apt-get ?
AmigaOs doesn't have dpkgs, it has modules. What L:System-Startup (or its ROM-version) does is that it replaces such modules.


This could mean UI elements can be updated with new features like auto crash reporting, UI dependency check/download
and also automated UI regression testing.
Well, for that you don't need System-startup. You can replace intuition boopsis right away without requiring a rom patch. But yes, intuition and gadtools are "loadable moduldes" system-startup can update from disk if it finds a newer version.


The most difficult part of programming Amiga API is figuring out how to interact safely with other libraries
Actually, the APIs are documented in the autodocs. Sometimes not as complete as they should, though.

At times I select a file and hit DEL expecting it to just delete. lol.
I suppose you mean on the workbench. Well, workbench is disk-based to begin with.