flashjazzcat Posted October 4, 2013 Share Posted October 4, 2013 (edited) 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 October 4, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
foft Posted October 4, 2013 Author Share Posted October 4, 2013 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? Quote Link to comment Share on other sites More sharing options...
foft Posted October 4, 2013 Author Share Posted October 4, 2013 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. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 4, 2013 Share Posted October 4, 2013 (edited) 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 October 4, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
foft Posted October 4, 2013 Author Share Posted October 4, 2013 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? Quote Link to comment Share on other sites More sharing options...
barnieg Posted October 4, 2013 Share Posted October 4, 2013 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/ Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 4, 2013 Share Posted October 4, 2013 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. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 4, 2013 Share Posted October 4, 2013 (edited) 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. Edited October 4, 2013 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 4, 2013 Share Posted October 4, 2013 Yes, the SDX formatter also uses the ANTIC display directly. But if you use video drivers, there's no conflict with VBXE display, as you already know. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 4, 2013 Share Posted October 4, 2013 Yes, the SDX formatter also uses the ANTIC display directly. But if you use video drivers, there's no conflict with VBXE display, as you already know. I wasn't saying there is... just saying it accesses the Antic display directly. Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 4, 2013 Share Posted October 4, 2013 Yes, I initially forgot about the formatter. Anyway, what I am saying is that it is display-driver aware. ED is not, which makes it exceptional. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 4, 2013 Share Posted October 4, 2013 Yes, I initially forgot about the formatter. Anyway, what I am saying is that it is display-driver aware. ED is not, which makes it exceptional. Indeed. Quote Link to comment Share on other sites More sharing options...
foft Posted October 4, 2013 Author Share Posted October 4, 2013 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. Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 4, 2013 Share Posted October 4, 2013 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 Quote Link to comment Share on other sites More sharing options...
foft Posted October 4, 2013 Author Share Posted October 4, 2013 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. Quote Link to comment Share on other sites More sharing options...
drac030 Posted October 5, 2013 Share Posted October 5, 2013 (edited) 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 October 5, 2013 by drac030 1 Quote Link to comment Share on other sites More sharing options...
l@k Posted October 12, 2013 Share Posted October 12, 2013 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 1 Quote Link to comment Share on other sites More sharing options...
ricortes Posted October 12, 2013 Share Posted October 12, 2013 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. Quote Link to comment Share on other sites More sharing options...
foft Posted October 18, 2013 Author Share Posted October 18, 2013 Had an hour for debugging... That might be it for October! 7 Quote Link to comment Share on other sites More sharing options...
Beetle Posted October 29, 2013 Share Posted October 29, 2013 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 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 29, 2013 Share Posted October 29, 2013 Wow - just noticed POKE 559,66... if only this unused bit worked on the real thing. Quote Link to comment Share on other sites More sharing options...
foft Posted October 29, 2013 Author Share Posted October 29, 2013 @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:) 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 29, 2013 Share Posted October 29, 2013 @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. Quote Link to comment Share on other sites More sharing options...
foft Posted October 29, 2013 Author Share Posted October 29, 2013 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. Quote Link to comment Share on other sites More sharing options...
JamesD Posted October 29, 2013 Share Posted October 29, 2013 @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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.