Jump to content
IGNORED

Potential new hardware


foft

Recommended Posts

It would be pretty great if any extended graphical capabilities could be made VBXE-compatible. Like it or not, VBXE is the nearest thing we have to a proliferating "standard" for extended graphics features (80 col, etc), and it has existing software and driver support. Just a suggestion. :)

Edited by flashjazzcat
Link to comment
Share on other sites

I can't get aspeqt to work (I use an USB-serial cable on my main Linux machine), so I can't test any games on CAS and test the joystick.

Once again, I'll have to wait for SD card support.

 

 

Excuses excuses ;)

 

Please run this in basic:

10 ? stick(0);" ";strig(0);" ";stick(1);" ";strig(1)

20 goto 10

 

I suggest buying an SIO2SD for SD card support. I started on SD card support however I want to finish my break out board first. It is very likely that I will be back at work before getting a chance to look at SD card support - so this will go SLOW!

 

For the serial to USB adaptor I suggest using an FTDI one. Though I'm pretty surprised that the cheap ones are not good enough for CAS. I'd have thought the cheap ones would just not implement RI or CSR lines which allow for the command line (required for disk drives). Remember its a _straight_ serial lead you need. Does RXD flash as you play the tape?

Link to comment
Share on other sites

It would be pretty great if any extended graphical capabilities could be made VBXE-compatible. Like it or not, VBXE is the nearest thing we have to a proliferating "standard" for extended graphics features (80 col, etc), and it has existing software and driver support. Just a suggestion. :)

 

The inclusion of VBXE is something that needs discussing further with the implementers of VBXE. As I understand it they are currently snowed under with work. It is certainly possible to put it into the FPGA but I have no plans to reimplement it myself.

 

Regarding 80-column mode couldn't an E: device be written? I have no pretensions of creating a new Atari 8-bit hardware standard, but it is nice to run some editors in 80 column mode. It should be fairly trivial to do the modifications I mentioned above - so bang for the buck is high.

Link to comment
Share on other sites

The inclusion of VBXE is something that needs discussing further with the implementers of VBXE. As I understand it they are currently snowed under with work. It is certainly possible to put it into the FPGA but I have no plans to reimplement it myself.

Absolutely: the VBXE firmware is IP which would need licensing, and would be the hardware concept I guess. It's emulated in Altirra, though. Candle would be the go-to guy.

 

Regarding 80-column mode couldn't an E: device be written? I have no pretensions of creating a new Atari 8-bit hardware standard, but it is nice to run some editors in 80 column mode. It should be fairly trivial to do the modifications I mentioned above - so bang for the buck is high.

E: devices exist already for soft-modes, XEP-80, etc, but I thought you were talking about doing a hardware 80-column mode. How it's accessed is academic: VBXE 80-column mode already has ample driver support in the form of Drac030's S_VBXE driver, which gives access to all the advanced modes right from BASIC, etc, via the CIO. It can be installed on any DOS, too. Much of the SpartaDOS X toolkit software, plus stuff I've written, runs in nice readable 80 column mode using S_VBXE.

Edited by flashjazzcat
Link to comment
Share on other sites

Absolutely: the VBXE firmware is IP which would need licensing, and would be the hardware concept I guess. It's emulated in Altirra, though. Candle would be the go-to guy.

 

 

E: devices exist already for soft-modes, XEP-80, etc, but I thought you were talking about doing a hardware 80-column mode. How it's accessed is academic: VBXE 80-column mode already has ample driver support in the form of Drac030's S_VBXE driver, which gives access to all the advanced modes right from BASIC, etc, via the CIO. It can be installed on any DOS, too. Much of the SpartaDOS X toolkit software, plus stuff I've written, runs in nice readable 80 column mode using S_VBXE.

 

Well perhaps we can share the interface for some basic modes. Where is the VBXE CIO interface documented?

Link to comment
Share on other sites

Absolutely: the VBXE firmware is IP which would need licensing, and would be the hardware concept I guess. It's emulated in Altirra, though. Candle would be the go-to guy.

 

 

E: devices exist already for soft-modes, XEP-80, etc, but I thought you were talking about doing a hardware 80-column mode. How it's accessed is academic: VBXE 80-column mode already has ample driver support in the form of Drac030's S_VBXE driver, which gives access to all the advanced modes right from BASIC, etc, via the CIO. It can be installed on any DOS, too. Much of the SpartaDOS X toolkit software, plus stuff I've written, runs in nice readable 80 column mode using S_VBXE.

 

Would this be easier to emulate?

 

http://atariage.com/forums/topic/184693-the-bit-3-full-view-80/

Link to comment
Share on other sites

E: devices exist already for soft-modes, XEP-80, etc, but I thought you were talking about doing a hardware 80-column mode. How it's accessed is academic: VBXE 80-column mode already has ample driver support in the form of Drac030's S_VBXE driver, which gives access to all the advanced modes right from BASIC, etc, via the CIO. It can be installed on any DOS, too. Much of the SpartaDOS X toolkit software, plus stuff I've written, runs in nice readable 80 column mode using S_VBXE.

 

The exact point behind the SDX video drivers is that you do not have to emulate the exact hardware. CON.SYS (80-column console) is actually hardware-abstracted, so are some other programs from the Toolkit which are capable of benefitting from an 80-column display, e.g. Eddy, SC, whatever else actually as nothing in SDX (except ED) uses direct display access. TT terminal for CP/M is also abstracted similarly.

 

Therefore it is enough to write a low-level video BIOS (S_VBXE is an example of such a BIOS, another one is RC_GR8.SYS) for a specific hardware to have good chances that all the SDX software which runs on VBXE 80-column display, will also run on the new hardware. The BIOS structure is documented with S_VBXE.SYS driver, and despite the fact that this particular driver has lots of features implemented, an implementation of a basic driver for just 80-column video should be fairly simple.

 

But yes, of course it would be nice to proliferate VBXE and FX code as de facto standard, especially if there already is some software which uses its hardware directly.

  • Like 1
Link to comment
Share on other sites

The exact point behind the SDX video drivers is that you do not have to emulate the exact hardware.

 

...

 

But yes, of course it would be nice to proliferate VBXE and FX code as de facto standard, especially if there already is some software which uses its hardware directly.

Well, of course hardware abstraction is great, but I only suggested VBXE because the drivers are already written, and new drivers for different hardware take time to write, as you know only too well. And as you point out, there's software (especially games) which accesses the hardware directly. I imagined it might be a time-saver all round, is all.

 

Don't forget the SDX formatter. :D

Edited by flashjazzcat
Link to comment
Share on other sites

Therefore it is enough to write a low-level video BIOS (S_VBXE is an example of such a BIOS, another one is RC_GR8.SYS) for a specific hardware to have good chances that all the SDX software which runs on VBXE 80-column display, will also run on the new hardware. The BIOS structure is documented with S_VBXE.SYS driver, and despite the fact that this particular driver has lots of features implemented, an implementation of a basic driver for just 80-column video should be fairly simple.

 

Excellent. Sounds like this will do for my needs. Is the source for s_vbxe.sys and rc_gr8.sys available?

 

I made a start on double/quad dot clock modes. I have a picture with some recognisable 80 column text if I 'poke 559,66'. Though a bit of hardware debugging needed - hsync timing is somehow getting out of whack in vblank (when gtia does its own reset)! I'm keeping pmgs at the original res for now.

Link to comment
Share on other sites

The S_VBXE.SYS is a bit too complicated to serve as an example, neither driver's source is public anyway, but apart of that I can offer any help you want.

 

Remeber however that these drivers only cooperate with SpartaDOS X, and the concept of video drivers virtually does not exist outside its software :)

Link to comment
Share on other sites

It would be good to get basic, a text viewer and some terminal software in 80 col mode. I guess the latter two may exist as sdx programs. Basic I guess uses E: so I should be able to look that up in the os manual. Would be good if I could make plot and drawto work too, width is already over 256 pixels so can't be that bad I hope.

 

Anyway I'm not sure about writing any software, was just playing around on the hardware side... Now the core custom chip impl is pretty reliable interesting to see what is easy to adjust.

Link to comment
Share on other sites

I would like to say that I'd write a driver for you, but in reality I am already so overloaded with various tasks, that I can't really promise anything. But, when you'll have a working 80-column text mode, let me know ;)

 

As a side note, I don't think a 16k pixel mode, even if interesting, is very practical. But a character mode with double the resolution of GR.0 will be interesting. It of course will not be so fast as in VBXE (blitter!), but will still look good, as the Atari system font in 80-column resolution is very elegant.

Edited by drac030
  • Like 1
Link to comment
Share on other sites

I would like to compliment the playability of the latest core - Its fantastic.

I've tried the serial (cas) and GPIO for the SIO2PC together with Aspeqt. Works nice and fast.

Minor issues:

1) Dropzone: Some blocks appeared on the left border when in the tile screen.

2) Seafox: Can't fire forward torpedo with the DE1 button - Perhaps you can put the button(s) on the PS2 keyboard?

 

I've never owned or use the Atari before. Thanks for sharing the core. Can't wait for your next update.

 

rgds from Singapore

  • Like 1
Link to comment
Share on other sites

It would be good to get basic, a text viewer and some terminal software in 80 col mode. I guess the latter two may exist as sdx programs. Basic I guess uses E: so I should be able to look that up in the os manual. Would be good if I could make plot and drawto work too, width is already over 256 pixels so can't be that bad I hope.

 

Anyway I'm not sure about writing any software, was just playing around on the hardware side... Now the core custom chip impl is pretty reliable interesting to see what is easy to adjust.

IMHO: It is not something to sweat. While I would like to see some enhancements, it isn't exactly a deal breaker. I felt passionate enough about to write an 80 column terminal program back in the day and some people still use Itay's Ice-T, just not enough to burn a lot of brain cells on. Ditto for things like processor upgrades since it would require two versions of programs to give backwards compatibility.

 

There's some basic problems with Atari hardware and OS that limit the usefulness of an 80 column display. I tested the OS screen output speed and the upper limit is about 800 characters per second in Graphics 0. There is a limited amount of software that uses the built in E: handler because of this. Most people just resorted to writing their own screen handlers. This means things like Atari BASIC will work in 80 column mode while everything from the Action! programming language to SpeedScript will fail.

 

Ditto for things like other enhanced graphic modes. Even if you could do 1200x800 in 64k colors, there isn't enough memory in an Atari to display the images. If you jumped that hurdle you'd still be limited by slow I/O.

Link to comment
Share on other sites

  • 2 weeks later...

This is so cool, great work, foft!

 

It there a pinout diagram to the GPIO pins? A friend borrowed me his Altirra DE1 board,

and i'm eager to test it. Is it possible to connect an XL keyboard directly? I don't have any

XEGS keyboard...

 

Greets,

Beetle

Link to comment
Share on other sites

@Beetle: If you pm me your email I'll send you the vhdl for the gpio (for pinout) and the schematic (untested) for the breakout board, which includes an xl keyboard socket.

 

@flashcatjazz: poke 559,64+32+2 is 160 column mode:) Perhaps a hardware mod could get close to this on the 'real thing'. Overclock antic 2x, vbxe for gtia and a mid line dmactl hack to extend lines. Alternatively we could plug in an fpga antic:)

  • Like 1
Link to comment
Share on other sites

@flashcatjazz: poke 559,64+32+2 is 160 column mode:)

 

Well - this is extremely cool use of bit 6. I take it this will work in hi-res mode too, yielding 640x192 and even 1280x192? With maybe doubled bit-depth as an option, this could be very interesting when all one wants is extra resolution and little else.

Link to comment
Share on other sites

 

Well - this is extremely cool use of bit 6. I take it this will work in hi-res mode too, yielding 640x192 and even 1280x192? With maybe doubled bit-depth as an option, this could be very interesting when all one wants is extra resolution and little else.

 

Yes exactly. Of course you can do mid scan line changes to bit 6 too.

Link to comment
Share on other sites

@Beetle: If you pm me your email I'll send you the vhdl for the gpio (for pinout) and the schematic (untested) for the breakout board, which includes an xl keyboard socket.

 

@flashcatjazz: poke 559,64+32+2 is 160 column mode:) Perhaps a hardware mod could get close to this on the 'real thing'. Overclock antic 2x, vbxe for gtia and a mid line dmactl hack to extend lines. Alternatively we could plug in an fpga antic:)

I say just build a replacement board for the 800 cpu board. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...