New PBI HDD

[+bob1200xl]

I read the APT document... I do not see any hardware requirements at all. What does it need besides an IDE register address? How do all these special sectors get written? Do you do all this in the BIOS? Any reason why your code would not work in my hardware?

 

The WIDE BIOS responds to SIO requests using the PBI protocol. You set up $300-$30B and WIDE executes the request - read, write, status,,, It is a very low-level attachment.

 

Bob

 

 

 

apt specs

side driver api

 

can't see rom on schematics, but just nvram - does this mean that driver should be installed and then used until battery serves?

not that i have some objections against that - just a bit diffrent approach

my guess is that it was easier this way than getting reasonable flash chip back then

[flashjazzcat]

I read the APT document... I do not see any hardware requirements at all.

 

This is the idea. The conformant driver implementation simply needs to use the data structures and low-level API described in the spec.

 

What does it need besides an IDE register address?

 

Nothing. The hardware interface is entirely down to the developer. The result is hardware abstraction, to the extent that the APT FDISK application works with all compliant drivers (at the moment, it works with SIDE and the IDE Plus 2.0 beta APT BIOS).

 

How do all these special sectors get written? Do you do all this in the BIOS?

 

The partitioning structure is entirely created by the partitioning software (FDISK). The only part of the driver itself which makes changes transparently to the calling application are the "mount partition" calls with the persistent flag set. Naturally the BIOS needs to be able to read the mapping slots and create a RAM-based partition table based on that information. Only the mounting function needs to scan through the entire linked list of partition entries, and dynamic mounting is optional anyway (i.e. implementation dependant).

 

Any reason why your code would not work in my hardware?

 

None, but the SIDE driver (the one I wrote) isn't PBI ROM code. I won't write a PBI driver until I get around to making a version for the KMK / JZ interface. KMK himself has already written an APT-compliant PBI ROM BIOS for IDE Plus 2.0, but it's been in private beta for a couple of months. He may be very well situated to write PBI code for your device, although I suspect he's extremely preoccupied at the moment.

 

The WIDE BIOS responds to SIO requests using the PBI protocol. You set up $300-$30B and WIDE executes the request - read, write, status,,, It is a very low-level attachment.

 

Yep - this is pretty much the way the APT BIOSes work.

 

Really, you could write an APT-compliant SPI driver which controls SD cards - anything at all. As long as all the SIO calls are the same.

Edited January 17, 2012 by flashjazzcat

[+bob1200xl]

WIDE is 65816 based and has plenty of linear memory (that's where the OS, internal cart, PBI code, bootROM, and config blocks sit). So, you can throw mega-tables up there for APT. Running code in upper memory is a little harder (best to map it down into the lower 64K, like the PBI code).

 

But, I'm a hardware guy - can't follow what you are doing with APT. The PBI code is currently about 450 bytes (which is the biggest program I have ever done), so you have lots of space for APT code. I can't tell what else you need, hardware - wise.

 

Bob

 

 

 

I read the APT document... I do not see any hardware requirements at all.

 

This is the idea. The conformant driver implementation simply needs to use the data structures and low-level API described in the spec.

 

What does it need besides an IDE register address?

 

Nothing. The hardware interface is entirely down to the developer. The result is hardware abstraction, to the extent that the APT FDISK application works with all compliant drivers (at the moment, it works with SIDE and the IDE Plus 2.0 beta APT BIOS).

 

How do all these special sectors get written? Do you do all this in the BIOS?

 

The partitioning structure is entirely created by the partitioning software (FDISK). The only part of the driver itself which makes changes transparently to the calling application are the "mount partition" calls with the persistent flag set. Naturally the BIOS needs to be able to read the mapping slots and create a RAM-based partition table based on that information. Only the mounting function needs to scan through the entire linked list of partition entries, and dynamic mounting is optional anyway (i.e. implementation dependant).

 

Any reason why your code would not work in my hardware?

 

None, but the SIDE driver (the one I wrote) isn't PBI ROM code. I won't write a PBI driver until I get around to making a version for the KMK / JZ interface. KMK himself has already written an APT-compliant PBI ROM BIOS for IDE Plus 2.0, but it's been in private beta for a couple of months. He may be very well situated to write PBI code for your device, although I suspect he's extremely preoccupied at the moment.

 

The WIDE BIOS responds to SIO requests using the PBI protocol. You set up $300-$30B and WIDE executes the request - read, write, status,,, It is a very low-level attachment.

 

Yep - this is pretty much the way the APT BIOSes work.

 

Really, you could write an APT-compliant SPI driver which controls SD cards - anything at all. As long as all the SIO calls are the same.

[flashjazzcat]

Sounds like a powerful device, Bob, which should be great fun to code for. As for anything else I need - a WIDE should suffice!

[venom4728a]

I will probably want one too:), when they are ready!

[+bf2k+]

Me Too!

[+bob1200xl]

Then you have to help us design it... What do you want it to do?

 

Bob

 

 

 

Me Too!

[+bf2k+]

Then you have to help us design it... What do you want it to do?

 

I wish I could help... but my skills are in machine control design and application of Programmable Logic Controllers, Human - Machine Interfaces and such... not PCB design.

 

But I can contribute ideas!

[flashjazzcat]

Well, as soon as I've written the PBI APT BIOS for the KMK / JZ, I'll throw the base code out there: it can then be regarded as a general purpose PBI driver which - by changing the hardware registers - can be adapted to most anything. Perhaps this will be useful if it's done soon enough.

[+bob1200xl]

Ahhh... no, not the hardware - the features. This hack will take up the major portion of a 1200XL (any XL, actually) so it needs to provide as many capabilities as possible. There will be a video enhancement that plugs into the GTIA card. What else does it really need to have in order to be useful?

 

Bob

 

 

 

 

 

 

Then you have to help us design it... What do you want it to do?

 

I wish I could help... but my skills are in machine control design and application of Programmable Logic Controllers, Human - Machine Interfaces and such... not PCB design.

 

But I can contribute ideas!

Edited January 19, 2012 by bob1200xl

[+bob1200xl]

Sounds great, but I can't find an attachment... (kidding)

 

Yes, I would expect that the hardware regs may not match. Do you need access to the extended regs? (mostly s/w RESET)

 

Bob

 

 

Well, as soon as I've written the PBI APT BIOS for the KMK / JZ, I'll throw the base code out there: it can then be regarded as a general purpose PBI driver which - by changing the hardware registers - can be adapted to most anything. Perhaps this will be useful if it's done soon enough.

[flashjazzcat]

Sounds great, but I can't find an attachment... (kidding)

 

Yes, I would expect that the hardware regs may not match. Do you need access to the extended regs? (mostly s/w RESET)

 

SIDE adds a device control register at $D5F8 which should assert $58 such and such a time after you write $00 and then $01 to it. If it does, the disk is present and ready. There's also a hardware ID at $D5F9 which aids greatly in device detection.

 

Key is whether the data bus is 8 or 16 bits wide. If it's 8 bits wide, we'll naturally rely on 8-bit PIO mode (as does SIDE). KMK / JZ and IDE Plus 2.0 take a somewhat different approach. When writing, for example, you store bits 8-15 first (in the IDE_DATA_HI register), then 0-7 (in the low register). When the latter is written by the CPU, the interface writes out all 16 bits.

 

Either approach works fine.

 

Anyway, it's a long time since I looked at my KMK / JZ code (since before APT was even conceived, in fact). I recall my ROM code locking up the machine at boot, but at the time there was no Altirra emulation of the interface. It shouldn't take long to debug it when I get a chance.

Edited January 19, 2012 by flashjazzcat

[candle]

Bob, have you heard of TQFP packages?

[+bob1200xl]

I think I've heard of them. Aren't they darned hard for the user to replace?

 

Heck, if I could solder something like a TQFP, I could put 2 megs of SRAM in there...

 

(you volunteering?)

 

Bob

 

 

Bob, have you heard of TQFP packages?

[candle]

i prefer to solder 4 pins (a bit wide ones) than 84

[falcon_]

Ahhh... no, not the hardware - the features. This hack will take up the major portion of a 1200XL (any XL, actually) so it needs to provide as many capabilities as possible. There will be a video enhancement that plugs into the GTIA card. What else does it really need to have in order to be useful?

 

Bob

 

Wha Wha?? This sounds interesting! Could you please elaborate, Bob?

Kwwl project folks!

[candle]

Ahhh... no, not the hardware - the features. This hack will take up the major portion of a 1200XL (any XL, actually) so it needs to provide as many capabilities as possible. There will be a video enhancement that plugs into the GTIA card. What else does it really need to have in order to be useful?

 

Bob

 

Wha Wha?? This sounds interesting! Could you please elaborate, Bob?

Kwwl project folks!

 

it will be like vbxe, only worse

[+bob1200xl]

It's going to like what you want - so, tell me what you want!

 

Basic function is to convert the Atari video to component output. You will lose artifacting, unless someone has a bright idea?

 

But, that's for later... I just allowed for it in the WIDE hardware.

 

Bob

 

 

 

Ahhh... no, not the hardware - the features. This hack will take up the major portion of a 1200XL (any XL, actually) so it needs to provide as many capabilities as possible. There will be a video enhancement that plugs into the GTIA card. What else does it really need to have in order to be useful?

 

Bob

 

Wha Wha?? This sounds interesting! Could you please elaborate, Bob?

Kwwl project folks!

[venom4728a]

Would it be possible to have the Atari output and accurately upscaled 31khz VGA signal?

 

Robert

[candle]

if that would be generic question, the answer is yes, but not 31khz vga, but 720p hdmi output

[venom4728a]

if that would be generic question, the answer is yes, but not 31khz vga, but 720p hdmi output

 

I Think that would work just as well, Many of todays modern tv/Monitors can display both dvi and HDMI. Saving desk space by using only one monitor for Atari and PC.

 

Robert

[+bob1200xl]

If you had a chip that would do the HDMI conversion... not going to happen in the Atari without it.

 

VGA is doable, isn't it?

 

The plan is to re-digitize the video and store it in a frame buffer. Goes in at NTSC, comes out as component. (or 640x480, I suppose)

 

Could we throw the last pixel into a register and use that value to tweak the next pixel? No change if they match. Some sort of skew if they do not? That's all artifacting really does.

 

If you are going to use one monitor on two systems, you either need two HDMI inputs or an HDMI (for the PC) and something else for the Atari - right?

 

Bob

[candle]

ntsc is simple, pal is not

not because of colour encoding, and artifacting, but because 50hz vertical frame rate

this is allright for component, or 720p, but not for majority of vga monitors

 

hdmi chips (tmds encoders) are dime and dozen

[venom4728a]

I was thinking of using a KVM switch (keyboard, Video, mouse) for VGA to switch over to the Atari when in use and back to PC when its needed. or get one of the TV//Monitors that can display HD TV and SVGA through separate inputs.

 

I have purchased the JAMMA rgb-vga upscaler, just have not got around to try it out yet.

 

If I Candle makes another run of his IO boards , Could use the PC Keyboard and mouse through the switch also. I think.

 

Robert

[flashjazzcat]

Heh... trust me to spend two years buying up 4:3 monitors with neither Component nor HDMI inputs... they all do VGA, though.