Welcome, Guest. Please login or register.

Author Topic: newb questions, hit the hardware or not?  (Read 33057 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline commodorejohn

  • Hero Member
  • *****
  • Join Date: Mar 2010
  • Posts: 3165
    • Show only replies by commodorejohn
    • http://www.commodorejohn.com
Re: newb questions, hit the hardware or not?
« Reply #134 from previous page: July 20, 2014, 01:48:36 PM »
Quote from: psxphill;769407
That sounds unmanageable to me, you seem to be confused between something being unmanageable and something existing. I'll give you the benefit of the doubt that you just don't understand the meaning of words rather than trying to bend the meaning on purpose
And I'll give you the benefit of the doubt and assume that you're a robot from space who does not understand the thing we hu-mans refer to as a "joke."
Computers: Amiga 1200, DEC VAXStation 4000/60, DEC MicroPDP-11/73
Synthesizers: Roland JX-10/MT-32/D-10, Oberheim Matrix-6, Yamaha DX7/FB-01, Korg MS-20 Mini, Ensoniq Mirage/SQ-80, Sequential Circuits Prophet-600, Hohner String Performer

"\'Legacy code\' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrup
 

Offline Thorham

  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1149
    • Show only replies by Thorham
Re: newb questions, hit the hardware or not?
« Reply #135 on: July 20, 2014, 02:17:30 PM »
Quote from: Thomas Richter;769428
Ok, here are a couple of ideas. Write a complete JPEG 2000 codec, from scratch, from the specs, in assembler. If that's not interesting enough, you can also start with HEVC (the latest MPEG standard), again from the specs. For the first project, I could give you help since I did this. For the second, I would be of no help since it's not exactly my branch.
I lack the math knowledge to implement these optimally, and they're boring to me. Also, MPEG is useless on my preferred targets (20's and 30's with some fastmem) because they're just not fast enough.

What about that GUI system I was talking about? This would be much more interesting for me, because it also requires designing everything. Coding from specs is boring to me, and I want the freedom to do what I want. It also doesn't seem to be a small project.
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #136 on: July 20, 2014, 02:36:45 PM »
Quote from: Thorham;769430
I lack the math knowledge to implement these optimally
So did I when I started. That's not an argument - learn it. You might experience something new.
Quote from: Thorham;769430
Also, MPEG is useless on my preferred targets (20's and 30's with some fastmem) because they're just not fast enough.
Then make it fast enough. (-;
Quote from: Thorham;769430
What about that GUI system I was talking about? This would be much more interesting for me, because it also requires designing everything. Coding from specs is boring to me, and I want the freedom to do what I want. It also doesn't seem to be a small project.

Real world software development is hardly ever "doing what you want". GUI systems, in a sense, are not very challenging, and neither very demanding (I wrote one for SDL in a matter of weeks, not months). Except that I would never do that in assembly, not even partially, because any other language is also fast enough, and has better means to express the dependencies of the objects. The challenge is here, rather, to come up with a good class design and a good documentation to actually make people use it.

So, please, let's come up with some projects that have a challenge in it due to their complexity. A GUI system is not that complex (been there, done that).
 

Offline Thorham

  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1149
    • Show only replies by Thorham
Re: newb questions, hit the hardware or not?
« Reply #137 on: July 20, 2014, 04:00:18 PM »
Quote from: Thomas Richter;769431
So did I when I started. That's not an argument - learn it. You might experience something new.  Then make it fast enough. (-;
Yeah, that probably is a bad argument, but it's just not my cup of tea.

Quote from: Thomas Richter;769431
Real world software development is hardly ever "doing what you want".
It is when you're doing it as a hobby. Not always, of course. You may end up having to write some things for your project that you don't feel like writing.

Quote from: Thomas Richter;769431
GUI systems, in a sense, are not very challenging, and neither very demanding (I wrote one for SDL in a matter of weeks, not months).
I'm talking about the larger projects like Gnome and KDE. These were undoubtedly not written in a couple of weeks.

Quote from: Thomas Richter;769431
So, please, let's come up with some projects that have a challenge in it due to their complexity. A GUI system is not that complex (been there, done that).
Perhaps not very complex, but also not very small, and a good, modern GUI system is quite useful at least.

The thing that's most interesting for me to do that's also complex is writing a new OS from scratch. Should be sufficiently challenging.
 

Offline psxphill

Re: newb questions, hit the hardware or not?
« Reply #138 on: July 20, 2014, 04:33:23 PM »
Quote from: LiveForIt;769411
Well it has to read the RAW data, decode the MFM, after the MFM is decoded can know whats on it, to see what block that was requested.

It doesn't need to do that for every block though, if you request a block from the last track read then it can skip steps.
 
Quote from: commodorejohn;769429
And I'll give you the benefit of the doubt and assume that you're a robot from space who does not understand the thing we hu-mans refer to as a "joke."

We humans call it sarcasm. I just thought your mobbing attempt should be debunked for it's inaccuracy.
 
Quote from: Thorham;769421
You're right, I haven't. Doesn't mean it's impossible.

There are lots of things that are theoretically possible but practically impossible. Usually because people over estimate their abilities and their theory was incomplete.
 
Quote from: Thomas Richter;769417
Actually, no. If you only had a single sync word, then PAULA had only a single chance of finding the sync word per track

Is this a big deal? Why wouldn't it find the sync word? If there are frequent bit errors then the floppy disk is going to fail anyway as there is no redundancy for all the data bits.
 
The only advantage I can think of is you can start reading sooner as you don't need to wait for the start of a track, but I'm not sure how much help that is if you need to re-arrange the track in ram anyway. Especially with the hokum that kickstart 1.x uses.
 
Quote from: LiveForIt;769411
On the other hand with no sectors, the be only one CRC for large block of 4489, so more data being lost if there was a read/write error, maybe diving it into sector made it more reliable I don't know.

You could use multiple CRC's, but if you're expecting errors then you could lose the only 4489. I don't know how well trackdisk copes with damaged sectors. Especially if it's the sector number that gets corrupted.
 
Quote from: Thomas Richter;769417
With the relatively short sector gap the Amiga trackdisk layout has, this would be rather impossible. The chance of overwriting the next sector would be very high. For the PCs, the uncertainty in write alignment is compensated with the higher inter-sector gap (i.e. the sector can overflow a little bit behind its natural location, then fills the sector gap without overwriting the next sector header).

Yes you would need to make the sector gap larger & I think they would have done that if paula had the functionality in. In write mode with sync turned on it does read from the disk and wait for the word sync. However there is no sector number comparison, my conjecture is that they may have started out down this path and given up due to time/available gates rather than a desire to do it all with the CPU.
 
Quote from: Thomas Richter;769417
From the RKRM description, you would have only gotten unaligned MFM data in the buffer after the track gap, and hence would need to re-align manually - which is what they did. However, PAULA is not that stupid.

I'd assumed that the hardware reference manual was written after trackdisk.device was. There will have been documentation, but exactly what we'll never know. The software and hardware engineers had the opportunity to talk to each other about how the hardware worked and supposedly they did on other occasions. It kinda worked well enough and fixing it might not have been seen as a priority, the developer might have been arrogant about his ability and never bothered to discuss it with anyone or he might have been arrogant enough to say that he'd tried making the hardware work and it didn't so he'd been forced to do it that way and nobody ever took him on.
 
The Kickstart 1.2 easter egg would suggest that it was released before development moved to commodore. My guess is that the trackdisk developer didn't transition to commodore, allowing any misinformation to disappear as to why it was coded like that.
 
Quote from: Thorham;769412
Anyone who says that managing big assembly language projects is impossible, is basically saying that we humans are too damned stupid for that. Speak for yourself, please.

You might want to read this:
 
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
 
My favourite quotes
 
"One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision."
 
"If you’re incompetent, you can’t know you’re incompetent. […] the skills you need to produce a right answer are exactly the skills you need to recognize what a right answer is."
 
Over the years I've often found people say things are impossible when they are possible, but say they are possible when they are impossible. It's usually down to whether they want to do something rather than any practical reasons.
 
Quote from: Thorham;769434
I'm talking about the larger projects like Gnome and KDE. These were undoubtedly not written in a couple of weeks.

You'd need to design it first, or you'll code yourself into a corner and end up constantly rewriting it all to get some new functionality that you think of tomorrow (and the next day). The problem with doing something for a hobby is that you don't have any external influence. If you don't manage scope then you're going to get bored
« Last Edit: July 20, 2014, 05:14:36 PM by psxphill »
 

Offline Thorham

  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1149
    • Show only replies by Thorham
Re: newb questions, hit the hardware or not?
« Reply #139 on: July 20, 2014, 05:05:48 PM »
Quote from: psxphill;769435
You might want to read this:
 
http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
I never said that I can take on large, complex projects in assembly language by myself and get it right, I said that it's not impossible to do large, complex projects in assembly language and do them properly. Although I'm fairly confident, I'd have to try and see for myself if I could do it or not.
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #140 on: July 20, 2014, 05:15:36 PM »
Quote from: psxphill;769435
Is this a big deal? Why wouldn't it find the sync word? If there are frequent bit errors then the floppy disk is going to fail anyway as there is no redundancy for all the data bits.

It's certainly not a big deal, but it makes on average floppy transfer roughly 50% slower. Reason being that with only a single sync word, PAULA would have to wait on average half a track to get to the sync word. With a sync on every sector, you miss on average a bit more than half a sector, which is not that bad.

In the end, we do not know why CBM took such decisions.  

For the history lesson on the sync register, I found that apparently trackdisk was written before PAULA was completed (back then called "Portia") and CBM decided not to update trackdisk for the new features but rather rush it out. AmigaOs was late anyhow. It's also interesting to note that the trackdisk in Kickstart 2.0 and above no longer requries user buffers in chip memory. In worst case, it copies data to a chip mem buffer, or decodes using the CPU, bypassing the blitter. The track buffer remains, of course, in chip ram. Thus, the ugly BufMemType hack for the FFS is actually no longer required (and should not be required by any sane device.)
 

Offline psxphill

Re: newb questions, hit the hardware or not?
« Reply #141 on: July 20, 2014, 05:45:07 PM »
Quote from: Thorham;769437
I never said that I can take on large, complex projects in assembly language by myself and get it right, I said that it's not impossible to do large, complex projects in assembly language and do them properly. Although I'm fairly confident, I'd have to try and see for myself if I could do it or not.

You don't have any idea what your own or anyone elses ability to achieve it is. You also don't have enough experience to evaluate your or anyone elses results.
 
If you read and understood the link I posted then saying it's possible to do it and being fairly confident you could do it yourself is a bad sign for your ability to actually do it. It will definitely have an effect on how long you think it will take and how long it will actually take.
 
Quote from: Thomas Richter;769438
For the history lesson on the sync register, I found that apparently trackdisk was written before PAULA was completed (back then called "Portia") and CBM decided not to update trackdisk for the new features but rather rush it out. AmigaOs was late anyhow.

Well that was my initial guess. While AmigaOS was late, so were the chips. Although that was partly commodore themselves switching AGNUS from YUV to RGB colour space. When they were hawking the breadboards round there was no floppy, sound and rs232 would be much more useful than floppy disk. I got the impression that trackdisk predated dos.library, but I find that kind of history really interesting. So any links etc would be great.
 
Quote from: Thomas Richter;769438
It's also interesting to note that the trackdisk in Kickstart 2.0 and above no longer requries user buffers in chip memory. In worst case, it copies data to a chip mem buffer, or decodes using the CPU, bypassing the blitter. The track buffer remains, of course, in chip ram. Thus, the ugly BufMemType hack for the FFS is actually no longer required (and should not be required by any sane device.)

I knew that you could use it to read into fast ram, but my knowledge (or at least my memory of) how that affects decoding is limited. The MFM decoding using the blitter is pretty insane, they could have implemented one pass MFM decoding and encoding into the blitter. On a chip ram only 68000 system it's probably still faster than using the CPU to do it though, on faster CPU's with fast ram then using a lookup table is probably much better.
 
I think you'd need to specify MEMF_24BITDMA in BufMemType for a Zorro II SCSI card in a Zorro III system with fast ram, but you might not consider that sane.
« Last Edit: July 20, 2014, 06:02:20 PM by psxphill »
 

Offline Thorham

  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1149
    • Show only replies by Thorham
Re: newb questions, hit the hardware or not?
« Reply #142 on: July 20, 2014, 06:18:06 PM »
Quote from: psxphill;769439
You don't have any idea what your own or anyone elses ability to achieve it is.
I know we can go to the moon, and drive remote controllable vehicles around on Mars, so I know that human beings have the ability to pull off some damn difficult things, and that's all I need to know. That there are possibilities where others see brick walls. If no one thought anything hard was possible, we'd still be stuck in the stone age. Can I do it? Don't know, haven't tried.

Quote from: psxphill;769439
If you read and understood the link I posted then saying it's possible to do it and being fairly confident you could do it yourself is a bad sign for your ability to actually do it.
With fairly confident I meant that I'm fairly confident in my programming ability, and I specifically said that I don't know if I could handle a large, complex project in assembly language by myself. Also, notice the word 'fairly', implying I know that I have some skill. How much? I don't know.

Anyway, all you're trying to say is how things are impossible, and I refuse to think like that, because I know things are not impossible, even though they may be very difficult.
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #143 on: July 20, 2014, 09:03:50 PM »
Quote from: psxphill;769439
I got the impression that trackdisk predated dos.library, but I find that kind of history really interesting. So any links etc would be great.
No official links on that, but I have other sources of information. (-: As far as the dos.library is concerned, I would say this rather depends on your definition. dos is just a rushed port of Tripos, and I would savely say that Tripos predates any CBM activities on the Amiga. But that's probably not what you are asking? Tripos is from 1979, some parts such as the OFS from 1980, trackdisk from 1985. Porting to Amiga also happened 1985, so it's hard to say which one came earlier.  
Quote from: psxphill;769439
I think you'd need to specify MEMF_24BITDMA in BufMemType for a Zorro II SCSI card in a Zorro III system with fast ram, but you might not consider that sane.

It is insane. Any driver worth its money should know which memory it can reach (by DMA or otherwise), and should take appropriate means to get the data into memory regions where it is accessible for it, possibly using additional buffers. At least, it should not be the matter of the *filing system* or the *user program* (shudder) to care about such implementation details. If a special memory type must be used, at least an interface should have existed to negotiate the requirements. Just depending on the user for this is a very lousy hack. Apparently, they didn't know what to do when FFS had direct buffer access and implemented a quick workaround by means of the BUFMEMTYPE. Argh.
 

Offline psxphill

Re: newb questions, hit the hardware or not?
« Reply #144 on: July 20, 2014, 11:30:31 PM »
Quote from: Thomas Richter;769449
dos is just a rushed port of Tripos

Yeah, they do seem to have ripped the guts out of it and transplanted it with exec devices reasonably well. But the whole BCPL thing is tragic. I don't think anything other than the 1.x C: directory ever used the a5 global vector (which was why they were impervious to the powerpackerpatcher & you had to use the ARP equivalents). I guess AROS 68k doesn't implement the global vector either, but I don't know.
 
Quote from: Thomas Richter;769449
It is insane. Any driver worth its money should know which memory it can reach (by DMA or otherwise), and should take appropriate means to get the data into memory regions where it is accessible for it, possibly using additional buffers.

Additional buffers is the wrong way to do it. Ideally you'd be able to ask for memory that you and another task can access and there would be some way of trackdisk.device or scsi.device to tell exec what memory it needed, the mmu pages for your task and the other task would then get setup properly so that the memory could be accessed.
 
This would change quite a lot though, I think with the way AllocMem works you need BufMemType. I'm not that bothered about that, MaxTransfer is much higher up my list of wtf.
« Last Edit: July 20, 2014, 11:35:18 PM by psxphill »
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: newb questions, hit the hardware or not?
« Reply #145 on: July 21, 2014, 02:36:34 AM »
Quote from: psxphill;769454

This would change quite a lot though, I think with the way AllocMem works you need BufMemType. I'm not that bothered about that, MaxTransfer is much higher up my list of wtf.


Wasnt MaxTransfer workaround for buggy harddisks that could not transfer more than 64K at once?
My Amigas: A500, Mac Mini and PowerBook
 

Offline psxphill

Re: newb questions, hit the hardware or not?
« Reply #146 on: July 21, 2014, 07:00:08 AM »
Quote from: itix;769461
Wasnt MaxTransfer workaround for buggy harddisks that could not transfer more than 64K at once?

You should be able to set MaxTransfer to ffffffff on ATA hard drives, there is a fixed upper limit of 1fffe which is impossible to exceed that should be hard coded in the device and you are then supposed to ask the drive how many words to transfer after issuing a command. commodore don't seem to know about the 1fffe limit & they assume it will transfer what they request.
 
The highest most ATA drives can transfer is 1fe00 because it always transfers multiples of 200 and 20000 would overflow the count. There is nothing to stop a drive from normally being able to transfer 1f800 bytes from only being able to transfer 800 one time because of temporary buffer constraints or sector remapping. If the drive doesn't transfer as much as you need it to then afterwards you're supposed to issue more commands.
 
There might be hard disks that react differently to how commodore expect them to, but the hard disks are operating within specification. commodore either never read it, or decided it was too hard to implement properly (maybe because it was written in assembler?).
 
Any problems with SCSI drives are likely to be caused by similar bugs in the relevant .device code. It sounds better if you have can convince everyone that it's the superiority of the Amiga that it requires kludges to work around bugs in cheap hard disks that were made by lesser people for the inferior PC.
« Last Edit: July 21, 2014, 07:39:20 AM by psxphill »
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #147 on: July 21, 2014, 09:50:19 AM »
Quote from: psxphill;769454
Additional buffers is the wrong way to do it. Ideally you'd be able to ask for memory that you and another task can access and there would be some way of trackdisk.device or scsi.device to tell exec what memory it needed, the mmu pages for your task and the other task would then get setup properly so that the memory could be accessed.
 
This would change quite a lot though, I think with the way AllocMem works you need BufMemType. I'm not that bothered about that, MaxTransfer is much higher up my list of wtf.

Look, the design principle is "the easy things should be easy". And reading a block from a device should be easy. If I - as caller - first have to make sure to get the proper memory, then the interface is already too complex, which will certainly create bugs by folks not following the interface. I would not have a problem with an interface that provides the *ideal* memory type for such users that want to optimize the throughput, but the overall design principle should be that a device can handle whatever the user provides, regardless of the buffer memory type or the transfer size. Everthing else is just asking for trouble.
 

Offline Thorham

  • Hero Member
  • *****
  • Join Date: Oct 2009
  • Posts: 1149
    • Show only replies by Thorham
Re: newb questions, hit the hardware or not?
« Reply #148 on: July 21, 2014, 10:46:19 AM »
Yeah, maxtransfer sucks turds. Use IdeFix and never worry about it again.
 

Offline psxphill

Re: newb questions, hit the hardware or not?
« Reply #149 on: July 21, 2014, 02:16:42 PM »
Quote from: Thomas Richter;769476
I would not have a problem with an interface that provides the *ideal* memory type for such users that want to optimize the throughput, but the overall design principle should be that a device can handle whatever the user provides, regardless of the buffer memory type or the transfer size. Everthing else is just asking for trouble.

I would prefer that you asked for memory that was applicable rather than adding lots of layers which will just slow everything down when you pass the wrong type of ram.
 
 
Quote from: Thorham;769442
I know we can go to the moon, and drive remote controllable vehicles around on Mars, so I know that human beings have the ability to pull off some damn difficult things, and that's all I need to know.

 Do you know that they spent a lot of money on high level language development so they didn't have to rely on someone writing a complex assembly language for the software for those projects?
« Last Edit: July 21, 2014, 02:23:01 PM by psxphill »