atari800-users Mailing List for Atari800
Brought to you by:
joy
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(97) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(28) |
Feb
(14) |
Mar
(26) |
Apr
(77) |
May
(5) |
Jun
(20) |
Jul
(51) |
Aug
(48) |
Sep
(23) |
Oct
(10) |
Nov
(21) |
Dec
(116) |
2003 |
Jan
(94) |
Feb
(105) |
Mar
(31) |
Apr
(31) |
May
(13) |
Jun
(14) |
Jul
(12) |
Aug
(26) |
Sep
(43) |
Oct
(21) |
Nov
(5) |
Dec
(17) |
2004 |
Jan
(12) |
Feb
(16) |
Mar
|
Apr
(3) |
May
(13) |
Jun
(9) |
Jul
(9) |
Aug
(10) |
Sep
(6) |
Oct
|
Nov
(13) |
Dec
(9) |
2005 |
Jan
(9) |
Feb
(3) |
Mar
(12) |
Apr
(3) |
May
(11) |
Jun
(5) |
Jul
(15) |
Aug
(25) |
Sep
(68) |
Oct
(44) |
Nov
(114) |
Dec
(83) |
2006 |
Jan
(165) |
Feb
(94) |
Mar
(58) |
Apr
(41) |
May
(28) |
Jun
(25) |
Jul
(1) |
Aug
|
Sep
|
Oct
(15) |
Nov
(17) |
Dec
(21) |
2007 |
Jan
(1) |
Feb
(3) |
Mar
|
Apr
(10) |
May
(26) |
Jun
(2) |
Jul
(14) |
Aug
|
Sep
(8) |
Oct
(1) |
Nov
(7) |
Dec
(1) |
2008 |
Jan
(3) |
Feb
(7) |
Mar
(18) |
Apr
(45) |
May
(44) |
Jun
(14) |
Jul
(3) |
Aug
(49) |
Sep
(14) |
Oct
(2) |
Nov
(9) |
Dec
(2) |
2009 |
Jan
(9) |
Feb
(12) |
Mar
(69) |
Apr
(4) |
May
(2) |
Jun
(20) |
Jul
|
Aug
(4) |
Sep
(18) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
2010 |
Jan
(98) |
Feb
(12) |
Mar
(6) |
Apr
(40) |
May
(22) |
Jun
(3) |
Jul
(22) |
Aug
(2) |
Sep
(3) |
Oct
(16) |
Nov
(14) |
Dec
(5) |
2011 |
Jan
(6) |
Feb
(2) |
Mar
(7) |
Apr
(52) |
May
(6) |
Jun
(11) |
Jul
(15) |
Aug
(17) |
Sep
(15) |
Oct
|
Nov
(1) |
Dec
(2) |
2012 |
Jan
|
Feb
|
Mar
(17) |
Apr
(2) |
May
(3) |
Jun
|
Jul
(4) |
Aug
|
Sep
(2) |
Oct
(19) |
Nov
|
Dec
|
2013 |
Jan
(7) |
Feb
(7) |
Mar
(39) |
Apr
(11) |
May
(5) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(6) |
Oct
(9) |
Nov
(2) |
Dec
(2) |
2014 |
Jan
(19) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(8) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(4) |
2015 |
Jan
|
Feb
(4) |
Mar
(20) |
Apr
(15) |
May
(5) |
Jun
(29) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(5) |
2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2017 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(9) |
Aug
(23) |
Sep
(21) |
Oct
(10) |
Nov
(2) |
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
(11) |
Apr
(28) |
May
(74) |
Jun
(30) |
Jul
(8) |
Aug
(1) |
Sep
|
Oct
(32) |
Nov
(4) |
Dec
(3) |
2019 |
Jan
(5) |
Feb
(1) |
Mar
|
Apr
(5) |
May
(1) |
Jun
(10) |
Jul
(5) |
Aug
|
Sep
(8) |
Oct
(7) |
Nov
(6) |
Dec
(3) |
2020 |
Jan
|
Feb
(7) |
Mar
|
Apr
(9) |
May
(5) |
Jun
|
Jul
|
Aug
(14) |
Sep
(9) |
Oct
(6) |
Nov
(3) |
Dec
(3) |
2021 |
Jan
|
Feb
(18) |
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(11) |
Aug
(17) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
(3) |
Jun
(4) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2023 |
Jan
(5) |
Feb
(1) |
Mar
(17) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(18) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(4) |
2025 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(2) |
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Miro K. <mir...@gm...> - 2025-06-27 20:52:00
|
Hi Jerzy, no problem. Specifically when it comes to atari800, my delays in reviewing and/or fixing things are comparably long. :-) We are about to prepare a new release (right, Petr? ;-)), so your contribution would be a welcomed addition for the release after this one. On Fri, 27 Jun 2025 at 20:41, Jerzy Kut via Atari800-users < ata...@li...> wrote: > Hello Miro. > First of all, excuse me please for a long delay with a reply to your > post. I haven't ignored it, but I got stuck in implementation of > specific memory extension (from Nevell Industries) what maps base memory > blocks in extended memory window and all this work stays unfinished till > now. In the meantime, reading old Polish magazine "Bajtek" I found other > extensions (coming from Polish companies TOMS and Karen), so my > intention is to describe all of these and propose better names for all > command line parameters to select specific extension. But I need to > finish this work at first. > Cheers > Jerzy Kut > > > W dniu 17.12.2024 o 23:33, Miro Kropáček pisze: > > Hi Jerzy, > > > > I have briefly gone through your branch, looks good to me. Feel free to > > create a PR from it. > > > > Just a couple of minor comments: > > > > - "-192" could indeed be named "-192xe" > > - "-192" is described as 192X*T*, is that a typo or intent? > > - it seems that you tried to clean up the rambo/compy shop naming but > > the descriptions were kept? (e.g. "-320|-rambo" is still described as > > "320XE" and then we have "-320xe" which is also described as > > "320XE") ... I'm not sure what makes "XE" being "XE" (default ROM used?) > > but perhaps we should omit those names and use something like "Atari > > with 320 KB (Compy Shop)" or something like that? Or at least explain > > the difference in the same file. > > > > On Sat, 14 Dec 2024 at 17:52, Jerzy Kut via Atari800-users <atari800- > > us...@li... <mailto:atari800- > > us...@li...>> wrote: > > > > Hi. I'm sorry, my fork is available here: > > https://github.com/mono6502/atari800/tree/ramext_256_576 <https:// > > github.com/mono6502/atari800/tree/ramext_256_576> . > > Regards > > Jerzy Kut > > > > W dniu 14.12.2024 o 17:33, Jerzy Kut pisze: > > > 576 KB Rambo was probably offered by mytek's Atari 576 NUC+. > > > Regards > > > Jerzy Kut > > > > > > > > > W dniu 14.12.2024 o 17:25, Jerzy Kut pisze: > > >> Hello. > > >> > > >> I've added support for a few PORTB managed extram types > > described in > > >> https://www.virtualdub.org/downloads/ <https:// > > www.virtualdub.org/downloads/> > > >> Altirra%20Hardware%20Reference%20Manual.pdf and http:// > > >> atariki.krap.pl/ <http://atariki.krap.pl/> index.php/ > > >> Obs%C5%82uga_standardowego_rozszerzenia_pami%C4%99ci_RAM > > >> and a new specific type of Rambo extension made nowadays by TFHH > > (it > > >> was really helpful when we're working on "Mikie" port by Vega). > > >> > > >> They are: > > >> - 192 KB (Karen) - a Compy Shop type extension with 128 KB (8 > > banks) > > >> of additional memory compatible with 130XE; it was offered in > > nineties > > >> of XX. century by PZ Karen company, which was official > > distributor of > > >> Atari for Poland, > > >> - 256 KB (Rambo) - a Rambo type extension with 192KB (12 banks) > of > > >> additional memory offered in nineties of XX. century by TOMS > > company > > >> in Poland: http://atariki.krap.pl/index.php/TOMS_260XE <http:// > > atariki.krap.pl/index.php/TOMS_260XE> > > >> - 576 KB (Rambo) - forgive me, I forgot who offers it, but it's > > >> described by Pharaon and the Atariki too, > > >> - 576 KB (TFHH) - a Rambo type extension with 512 KB (32 banks) > of > > >> additional memory offered nowadays by Jurgen van Radecke: > https:// > > >> www.van-radecke.de/STUFF/tfhh_HW_info.pdf <http://www.van- > > radecke.de/STUFF/tfhh_HW_info.pdf> > > >> > > >> These types of ram extensions can be enabled from command line > > using: > > >> -192 (maybe 192xe will be better?) > > >> -256 > > >> -320 (as well as -rambo using so far) > > >> -576 > > >> -576tfhh > > >> > > >> Additionally more info (mostly useful for developers) is > presented > > >> during amount of ram is selected in UI: > > >> - separate ANTIC and CPU access (ANTIC-CPU) or common one > > (ANTIC+CPU) > > >> - all bits and their order using to bank selection ("*" marks > > CPU and > > >> ANTIC enabling bits, "_" bits not used to select bank) > > >> - a number of banks. > > >> > > >> You can see examples on screenshots: > > >> - https://mono.i-demo.pl/atari800/ramsize-karen.png <https:// > > mono.i-demo.pl/atari800/ramsize-karen.png> > > >> - https://mono.i-demo.pl/atari800/ramsize-tfhh.png <https:// > > mono.i-demo.pl/atari800/ramsize-tfhh.png> > > >> > > >> I've not implemented Newell Industries extensions because I've > > never > > >> seen them and know only from papers. I've not implemented so > called > > >> "Jet extension" which was offered years ago by the scener Jet > > and was > > >> a bit exotic - only half banks was available for ANTIC, because > > ANTIC > > >> bit was involved in bank selection - this extension is known by > me > > >> only from chats with Polish sceners and I've never seen working > > >> example of it too. > > >> > > >> I could make pull request with this work. > > >> Best regards > > >> Jerzy Kut > > > > > > > > > > > > > > > _______________________________________________ > > Atari800-users mailing list > > Ata...@li... <mailto:Atari800- > > us...@li...> > > https://lists.sourceforge.net/lists/listinfo/atari800-users > > <https://lists.sourceforge.net/lists/listinfo/atari800-users> > > > > > > > > -- > > http://mikro.atari.org <http://mikro.atari.org> > > > > > > > > > > _______________________________________________ > > Atari800-users mailing list > > Ata...@li... > > https://lists.sourceforge.net/lists/listinfo/atari800-users > > > > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... > https://lists.sourceforge.net/lists/listinfo/atari800-users > -- http://mikro.atari.org |
From: Jerzy K. <jer...@po...> - 2025-06-27 18:50:59
|
Hello. I made a small pull request with the patch for a .CAS files without description. The problem was that fread requested 0 bytes and returned with error. Regards Jerzy Kut |
From: Jerzy K. <jer...@po...> - 2025-06-27 18:41:06
|
Hello Miro. First of all, excuse me please for a long delay with a reply to your post. I haven't ignored it, but I got stuck in implementation of specific memory extension (from Nevell Industries) what maps base memory blocks in extended memory window and all this work stays unfinished till now. In the meantime, reading old Polish magazine "Bajtek" I found other extensions (coming from Polish companies TOMS and Karen), so my intention is to describe all of these and propose better names for all command line parameters to select specific extension. But I need to finish this work at first. Cheers Jerzy Kut W dniu 17.12.2024 o 23:33, Miro Kropáček pisze: > Hi Jerzy, > > I have briefly gone through your branch, looks good to me. Feel free to > create a PR from it. > > Just a couple of minor comments: > > - "-192" could indeed be named "-192xe" > - "-192" is described as 192X*T*, is that a typo or intent? > - it seems that you tried to clean up the rambo/compy shop naming but > the descriptions were kept? (e.g. "-320|-rambo" is still described as > "320XE" and then we have "-320xe" which is also described as > "320XE") ... I'm not sure what makes "XE" being "XE" (default ROM used?) > but perhaps we should omit those names and use something like "Atari > with 320 KB (Compy Shop)" or something like that? Or at least explain > the difference in the same file. > > On Sat, 14 Dec 2024 at 17:52, Jerzy Kut via Atari800-users <atari800- > us...@li... <mailto:atari800- > us...@li...>> wrote: > > Hi. I'm sorry, my fork is available here: > https://github.com/mono6502/atari800/tree/ramext_256_576 <https:// > github.com/mono6502/atari800/tree/ramext_256_576> . > Regards > Jerzy Kut > > W dniu 14.12.2024 o 17:33, Jerzy Kut pisze: > > 576 KB Rambo was probably offered by mytek's Atari 576 NUC+. > > Regards > > Jerzy Kut > > > > > > W dniu 14.12.2024 o 17:25, Jerzy Kut pisze: > >> Hello. > >> > >> I've added support for a few PORTB managed extram types > described in > >> https://www.virtualdub.org/downloads/ <https:// > www.virtualdub.org/downloads/> > >> Altirra%20Hardware%20Reference%20Manual.pdf and http:// > >> atariki.krap.pl/ <http://atariki.krap.pl/> index.php/ > >> Obs%C5%82uga_standardowego_rozszerzenia_pami%C4%99ci_RAM > >> and a new specific type of Rambo extension made nowadays by TFHH > (it > >> was really helpful when we're working on "Mikie" port by Vega). > >> > >> They are: > >> - 192 KB (Karen) - a Compy Shop type extension with 128 KB (8 > banks) > >> of additional memory compatible with 130XE; it was offered in > nineties > >> of XX. century by PZ Karen company, which was official > distributor of > >> Atari for Poland, > >> - 256 KB (Rambo) - a Rambo type extension with 192KB (12 banks) of > >> additional memory offered in nineties of XX. century by TOMS > company > >> in Poland: http://atariki.krap.pl/index.php/TOMS_260XE <http:// > atariki.krap.pl/index.php/TOMS_260XE> > >> - 576 KB (Rambo) - forgive me, I forgot who offers it, but it's > >> described by Pharaon and the Atariki too, > >> - 576 KB (TFHH) - a Rambo type extension with 512 KB (32 banks) of > >> additional memory offered nowadays by Jurgen van Radecke: https:// > >> www.van-radecke.de/STUFF/tfhh_HW_info.pdf <http://www.van- > radecke.de/STUFF/tfhh_HW_info.pdf> > >> > >> These types of ram extensions can be enabled from command line > using: > >> -192 (maybe 192xe will be better?) > >> -256 > >> -320 (as well as -rambo using so far) > >> -576 > >> -576tfhh > >> > >> Additionally more info (mostly useful for developers) is presented > >> during amount of ram is selected in UI: > >> - separate ANTIC and CPU access (ANTIC-CPU) or common one > (ANTIC+CPU) > >> - all bits and their order using to bank selection ("*" marks > CPU and > >> ANTIC enabling bits, "_" bits not used to select bank) > >> - a number of banks. > >> > >> You can see examples on screenshots: > >> - https://mono.i-demo.pl/atari800/ramsize-karen.png <https:// > mono.i-demo.pl/atari800/ramsize-karen.png> > >> - https://mono.i-demo.pl/atari800/ramsize-tfhh.png <https:// > mono.i-demo.pl/atari800/ramsize-tfhh.png> > >> > >> I've not implemented Newell Industries extensions because I've > never > >> seen them and know only from papers. I've not implemented so called > >> "Jet extension" which was offered years ago by the scener Jet > and was > >> a bit exotic - only half banks was available for ANTIC, because > ANTIC > >> bit was involved in bank selection - this extension is known by me > >> only from chats with Polish sceners and I've never seen working > >> example of it too. > >> > >> I could make pull request with this work. > >> Best regards > >> Jerzy Kut > > > > > > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... <mailto:Atari800- > us...@li...> > https://lists.sourceforge.net/lists/listinfo/atari800-users > <https://lists.sourceforge.net/lists/listinfo/atari800-users> > > > > -- > http://mikro.atari.org <http://mikro.atari.org> > > > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... > https://lists.sourceforge.net/lists/listinfo/atari800-users |
From: <bb...@be...> - 2025-06-21 03:51:55
|
On Thu, 19 Jun 2025 12:47:39 -0500 Thom Cherryhomes <tho...@gm...> wrote: > Thank you very much for merging in netsio into the main atari800 tree. > > -Thom from FujiNet Yes, got it working with mbedtls-2.28 and fujinet-firmware-1.5.0. Thanks to everyone involved. |
From: Thom C. <tho...@gm...> - 2025-06-19 17:48:01
|
Thank you very much for merging in netsio into the main atari800 tree. -Thom from FujiNet |
From: Bill K. <nb...@so...> - 2025-04-23 08:17:47
|
I'm jazzed and eager to play with it! Thanks for sharing the news, Petr, and thanks to Andrew for the effort! -bill! On Tue, Apr 22, 2025 at 09:40:37PM +0200, Petr Stehlík wrote: > -------- Forwarded Message -------- > From: Andrew Diller > To: pst...@so... > Subject: atari800 emulator > Date: Tue, 22 Apr 2025 15:27:20 -0400 > > Hello- > > I wanted to drop you a note that i've started working on implementing > FujiNet for all SIO traffic on the atari800 emulator. > > > https://github.com/dillera/atari800/blob/fujinet2/FUJINET_README.md > > I'm not done but from my recent work I know it will involve some deep > changes in sio.c and some in pokey.c and cpu.c. > > Just wanted to let you know so that we can figure out how to handle a > PR sometime in the future. > > thanks, > > -andy > > > > > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... > https://lists.sourceforge.net/lists/listinfo/atari800-users > |
From: Petr S. <pst...@so...> - 2025-04-22 19:41:26
|
-------- Forwarded Message -------- From: Andrew Diller To: pst...@so... Subject: atari800 emulator Date: Tue, 22 Apr 2025 15:27:20 -0400 Hello- I wanted to drop you a note that i've started working on implementing FujiNet for all SIO traffic on the atari800 emulator. https://github.com/dillera/atari800/blob/fujinet2/FUJINET_README.md I'm not done but from my recent work I know it will involve some deep changes in sio.c and some in pokey.c and cpu.c. Just wanted to let you know so that we can figure out how to handle a PR sometime in the future. thanks, -andy |
From: Christian G. <ch...@gr...> - 2025-03-25 18:17:31
|
On 3/24/25 23:03, Petr Stehlík wrote: > On Po, 2025-03-24 at 20:55 +0100, Christian Groessler wrote: > >> The virtual register could be at any address I think. Maybe something >> like having four writes to address (say) $FFFF with values $AA, $BB, >> $CC, $DD. atari800 would detect this > Wow, knocking on an address, that's smart. I didn't think of that. But > it makes the routine calling the host rather long. Yes, it was just a general idea. And it would be more complicated if the ROM is banked out. Maybe better use some address in the zero page. regards, chris |
From: Petr S. <pst...@so...> - 2025-03-24 22:22:59
|
On Po, 2025-03-24 at 20:55 +0100, Christian Groessler wrote: > > > Is something like this already implemented? If not, I would try > > > to > > > implement it. Do you have ideas how the "Atari program" <--> > > > "atari800 emulator" communication should look like? > > Two obvious choices: either a virtual HW register or an > > illegal/unused > > CPU opcode. The virtual register approach is more error prone, I > > feel, > > so I'd go for a special CPU opcode. I think it would be smart to > > implement something compatible with another emulator as I guess > > other > > Atari800 emulators implemented similar thing already. > > > I'm tending towards a virtual register. If run on real hardware the > program shouldn't crash IMO. There are many undocumented opcodes that don't cause CPU crash (on a real 6502). > The virtual register could be at any address I think. Maybe something > like having four writes to address (say) $FFFF with values $AA, $BB, > $CC, $DD. atari800 would detect this Wow, knocking on an address, that's smart. I didn't think of that. But it makes the routine calling the host rather long. Petr |
From: Christian G. <ch...@gr...> - 2025-03-24 20:20:23
|
On 6/26/21 15:38, Petr Stehlík wrote: > On Ne, 2021-06-20 at 15:20 +0200, Christian Groessler wrote: >> For this to work I would need a way to terminate atari800 from within >> an Atari program. (Maybe also an emulator detection would be nice.) >> >> Is something like this already implemented? If not, I would try to >> implement it. Do you have ideas how the "Atari program" <--> >> "atari800 emulator" communication should look like? > Two obvious choices: either a virtual HW register or an illegal/unused > CPU opcode. The virtual register approach is more error prone, I feel, > so I'd go for a special CPU opcode. I think it would be smart to > implement something compatible with another emulator as I guess other > Atari800 emulators implemented similar thing already. I'm tending towards a virtual register. If run on real hardware the program shouldn't crash IMO. The virtual register could be at any address I think. Maybe something like having four writes to address (say) $FFFF with values $AA, $BB, $CC, $DD. atari800 would detect this and use contents of X and Y or maybe stack as pointer to some communication buffer. It could handle the request and return with e.g. ZF set (or so), so the 6502 program knows that the request was handled. regards, chris (I know. Late follow-up to this thread. :-) ) |
From: <zy...@po...> - 2025-01-27 08:11:42
|
Hello Dan, Yes, it is true that some cartridges do STA into the cartridge address space, verifying if the address space dedicated for cartridges is read-only. This could have been used as a simple anti-piracy measure. The memory management unit of the 8-bit Atari computers ensures that, when a cartridge is present, data go only to the cartridge and not to the computer's RAM chips. And since the cartridges hold ROM, the writes are effectively ignored. When it comes to .ATRs, these are floppy disk images, so the emulator treats them as a floppy disks inserted in a disk drive. Of course, real floppy disks had write protection capability - either piece of adhesive tape covering the write enable notch, or a sliding write protection tab. The .ATR files have a bit in them indicating if the write protection is on or off. The floppy drive emulated by atari800 honors the write protection bit. Also allows you to open the .ATR file as read only, regardless the bit. Michael " Hi. I think some atari800 cartridges like to STA into the code in their ROM region with an invalid instruction, to deter copying. Does atari800 treat .atr's as ROM? Thanks for the cool emulator :) _______________________________________________ Atari800-users mailing list Ata...@li... https://lists.sourceforge.net/lists/listinfo/atari800-users " |
From: Dan S. <str...@gm...> - 2025-01-26 20:46:48
|
Hi. I think some atari800 cartridges like to STA into the code in their ROM region with an invalid instruction, to deter copying. Does atari800 treat .atr's as ROM? Thanks for the cool emulator :) |
From: Miro K. <mir...@gm...> - 2024-12-17 22:34:18
|
Hi Jerzy, I have briefly gone through your branch, looks good to me. Feel free to create a PR from it. Just a couple of minor comments: - "-192" could indeed be named "-192xe" - "-192" is described as 192X*T*, is that a typo or intent? - it seems that you tried to clean up the rambo/compy shop naming but the descriptions were kept? (e.g. "-320|-rambo" is still described as "320XE" and then we have "-320xe" which is also described as "320XE") ... I'm not sure what makes "XE" being "XE" (default ROM used?) but perhaps we should omit those names and use something like "Atari with 320 KB (Compy Shop)" or something like that? Or at least explain the difference in the same file. On Sat, 14 Dec 2024 at 17:52, Jerzy Kut via Atari800-users < ata...@li...> wrote: > Hi. I'm sorry, my fork is available here: > https://github.com/mono6502/atari800/tree/ramext_256_576 . > Regards > Jerzy Kut > > W dniu 14.12.2024 o 17:33, Jerzy Kut pisze: > > 576 KB Rambo was probably offered by mytek's Atari 576 NUC+. > > Regards > > Jerzy Kut > > > > > > W dniu 14.12.2024 o 17:25, Jerzy Kut pisze: > >> Hello. > >> > >> I've added support for a few PORTB managed extram types described in > >> https://www.virtualdub.org/downloads/ > >> Altirra%20Hardware%20Reference%20Manual.pdf and http:// > >> atariki.krap.pl/ index.php/ > >> Obs%C5%82uga_standardowego_rozszerzenia_pami%C4%99ci_RAM > >> and a new specific type of Rambo extension made nowadays by TFHH (it > >> was really helpful when we're working on "Mikie" port by Vega). > >> > >> They are: > >> - 192 KB (Karen) - a Compy Shop type extension with 128 KB (8 banks) > >> of additional memory compatible with 130XE; it was offered in nineties > >> of XX. century by PZ Karen company, which was official distributor of > >> Atari for Poland, > >> - 256 KB (Rambo) - a Rambo type extension with 192KB (12 banks) of > >> additional memory offered in nineties of XX. century by TOMS company > >> in Poland: http://atariki.krap.pl/index.php/TOMS_260XE > >> - 576 KB (Rambo) - forgive me, I forgot who offers it, but it's > >> described by Pharaon and the Atariki too, > >> - 576 KB (TFHH) - a Rambo type extension with 512 KB (32 banks) of > >> additional memory offered nowadays by Jurgen van Radecke: https:// > >> www.van-radecke.de/STUFF/tfhh_HW_info.pdf > >> > >> These types of ram extensions can be enabled from command line using: > >> -192 (maybe 192xe will be better?) > >> -256 > >> -320 (as well as -rambo using so far) > >> -576 > >> -576tfhh > >> > >> Additionally more info (mostly useful for developers) is presented > >> during amount of ram is selected in UI: > >> - separate ANTIC and CPU access (ANTIC-CPU) or common one (ANTIC+CPU) > >> - all bits and their order using to bank selection ("*" marks CPU and > >> ANTIC enabling bits, "_" bits not used to select bank) > >> - a number of banks. > >> > >> You can see examples on screenshots: > >> - https://mono.i-demo.pl/atari800/ramsize-karen.png > >> - https://mono.i-demo.pl/atari800/ramsize-tfhh.png > >> > >> I've not implemented Newell Industries extensions because I've never > >> seen them and know only from papers. I've not implemented so called > >> "Jet extension" which was offered years ago by the scener Jet and was > >> a bit exotic - only half banks was available for ANTIC, because ANTIC > >> bit was involved in bank selection - this extension is known by me > >> only from chats with Polish sceners and I've never seen working > >> example of it too. > >> > >> I could make pull request with this work. > >> Best regards > >> Jerzy Kut > > > > > > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... > https://lists.sourceforge.net/lists/listinfo/atari800-users > -- http://mikro.atari.org |
From: Jerzy K. <jer...@po...> - 2024-12-14 16:57:54
|
576 KB Rambo was probably offered by mytek's Atari 576 NUC+. Regards Jerzy Kut W dniu 14.12.2024 o 17:25, Jerzy Kut pisze: > Hello. > > I've added support for a few PORTB managed extram types described in > https://www.virtualdub.org/downloads/ > Altirra%20Hardware%20Reference%20Manual.pdf and http://atariki.krap.pl/ > index.php/Obs%C5%82uga_standardowego_rozszerzenia_pami%C4%99ci_RAM > and a new specific type of Rambo extension made nowadays by TFHH (it was > really helpful when we're working on "Mikie" port by Vega). > > They are: > - 192 KB (Karen) - a Compy Shop type extension with 128 KB (8 banks) of > additional memory compatible with 130XE; it was offered in nineties of > XX. century by PZ Karen company, which was official distributor of Atari > for Poland, > - 256 KB (Rambo) - a Rambo type extension with 192KB (12 banks) of > additional memory offered in nineties of XX. century by TOMS company in > Poland: http://atariki.krap.pl/index.php/TOMS_260XE > - 576 KB (Rambo) - forgive me, I forgot who offers it, but it's > described by Pharaon and the Atariki too, > - 576 KB (TFHH) - a Rambo type extension with 512 KB (32 banks) of > additional memory offered nowadays by Jurgen van Radecke: https:// > www.van-radecke.de/STUFF/tfhh_HW_info.pdf > > These types of ram extensions can be enabled from command line using: > -192 (maybe 192xe will be better?) > -256 > -320 (as well as -rambo using so far) > -576 > -576tfhh > > Additionally more info (mostly useful for developers) is presented > during amount of ram is selected in UI: > - separate ANTIC and CPU access (ANTIC-CPU) or common one (ANTIC+CPU) > - all bits and their order using to bank selection ("*" marks CPU and > ANTIC enabling bits, "_" bits not used to select bank) > - a number of banks. > > You can see examples on screenshots: > - https://mono.i-demo.pl/atari800/ramsize-karen.png > - https://mono.i-demo.pl/atari800/ramsize-tfhh.png > > I've not implemented Newell Industries extensions because I've never > seen them and know only from papers. I've not implemented so called "Jet > extension" which was offered years ago by the scener Jet and was a bit > exotic - only half banks was available for ANTIC, because ANTIC bit was > involved in bank selection - this extension is known by me only from > chats with Polish sceners and I've never seen working example of it too. > > I could make pull request with this work. > Best regards > Jerzy Kut |
From: Jerzy K. <jer...@po...> - 2024-12-14 16:51:47
|
Hi. I'm sorry, my fork is available here: https://github.com/mono6502/atari800/tree/ramext_256_576 . Regards Jerzy Kut W dniu 14.12.2024 o 17:33, Jerzy Kut pisze: > 576 KB Rambo was probably offered by mytek's Atari 576 NUC+. > Regards > Jerzy Kut > > > W dniu 14.12.2024 o 17:25, Jerzy Kut pisze: >> Hello. >> >> I've added support for a few PORTB managed extram types described in >> https://www.virtualdub.org/downloads/ >> Altirra%20Hardware%20Reference%20Manual.pdf and http:// >> atariki.krap.pl/ index.php/ >> Obs%C5%82uga_standardowego_rozszerzenia_pami%C4%99ci_RAM >> and a new specific type of Rambo extension made nowadays by TFHH (it >> was really helpful when we're working on "Mikie" port by Vega). >> >> They are: >> - 192 KB (Karen) - a Compy Shop type extension with 128 KB (8 banks) >> of additional memory compatible with 130XE; it was offered in nineties >> of XX. century by PZ Karen company, which was official distributor of >> Atari for Poland, >> - 256 KB (Rambo) - a Rambo type extension with 192KB (12 banks) of >> additional memory offered in nineties of XX. century by TOMS company >> in Poland: http://atariki.krap.pl/index.php/TOMS_260XE >> - 576 KB (Rambo) - forgive me, I forgot who offers it, but it's >> described by Pharaon and the Atariki too, >> - 576 KB (TFHH) - a Rambo type extension with 512 KB (32 banks) of >> additional memory offered nowadays by Jurgen van Radecke: https:// >> www.van-radecke.de/STUFF/tfhh_HW_info.pdf >> >> These types of ram extensions can be enabled from command line using: >> -192 (maybe 192xe will be better?) >> -256 >> -320 (as well as -rambo using so far) >> -576 >> -576tfhh >> >> Additionally more info (mostly useful for developers) is presented >> during amount of ram is selected in UI: >> - separate ANTIC and CPU access (ANTIC-CPU) or common one (ANTIC+CPU) >> - all bits and their order using to bank selection ("*" marks CPU and >> ANTIC enabling bits, "_" bits not used to select bank) >> - a number of banks. >> >> You can see examples on screenshots: >> - https://mono.i-demo.pl/atari800/ramsize-karen.png >> - https://mono.i-demo.pl/atari800/ramsize-tfhh.png >> >> I've not implemented Newell Industries extensions because I've never >> seen them and know only from papers. I've not implemented so called >> "Jet extension" which was offered years ago by the scener Jet and was >> a bit exotic - only half banks was available for ANTIC, because ANTIC >> bit was involved in bank selection - this extension is known by me >> only from chats with Polish sceners and I've never seen working >> example of it too. >> >> I could make pull request with this work. >> Best regards >> Jerzy Kut > |
From: Jerzy K. <jer...@po...> - 2024-12-14 16:48:54
|
Hello. I've added support for a few PORTB managed extram types described in https://www.virtualdub.org/downloads/Altirra%20Hardware%20Reference%20Manual.pdf and http://atariki.krap.pl/index.php/Obs%C5%82uga_standardowego_rozszerzenia_pami%C4%99ci_RAM and a new specific type of Rambo extension made nowadays by TFHH (it was really helpful when we're working on "Mikie" port by Vega). They are: - 192 KB (Karen) - a Compy Shop type extension with 128 KB (8 banks) of additional memory compatible with 130XE; it was offered in nineties of XX. century by PZ Karen company, which was official distributor of Atari for Poland, - 256 KB (Rambo) - a Rambo type extension with 192KB (12 banks) of additional memory offered in nineties of XX. century by TOMS company in Poland: http://atariki.krap.pl/index.php/TOMS_260XE - 576 KB (Rambo) - forgive me, I forgot who offers it, but it's described by Pharaon and the Atariki too, - 576 KB (TFHH) - a Rambo type extension with 512 KB (32 banks) of additional memory offered nowadays by Jurgen van Radecke: https://www.van-radecke.de/STUFF/tfhh_HW_info.pdf These types of ram extensions can be enabled from command line using: -192 (maybe 192xe will be better?) -256 -320 (as well as -rambo using so far) -576 -576tfhh Additionally more info (mostly useful for developers) is presented during amount of ram is selected in UI: - separate ANTIC and CPU access (ANTIC-CPU) or common one (ANTIC+CPU) - all bits and their order using to bank selection ("*" marks CPU and ANTIC enabling bits, "_" bits not used to select bank) - a number of banks. You can see examples on screenshots: - https://mono.i-demo.pl/atari800/ramsize-karen.png - https://mono.i-demo.pl/atari800/ramsize-tfhh.png I've not implemented Newell Industries extensions because I've never seen them and know only from papers. I've not implemented so called "Jet extension" which was offered years ago by the scener Jet and was a bit exotic - only half banks was available for ANTIC, because ANTIC bit was involved in bank selection - this extension is known by me only from chats with Polish sceners and I've never seen working example of it too. I could make pull request with this work. Best regards Jerzy Kut |
From: Lee H. <le...@vr...> - 2024-11-18 11:00:26
|
Try my installer script. This works for Kubuntu. https://github.com/VR51/Atari800-Installer I still use this script when I rebuild Atari800 on my own system. I'm not actively working on my script but you might get a few hints from it. The script has an option to install build dependencies. Feel free to fork it. Use at your own risk. On Mon, Nov 18, 2024 at 7:50 AM Miro Kropáček <mir...@gm...> wrote: > On Mon, 18 Nov 2024 at 01:41, Chris Chiesa <chr...@gm...> wrote: > >> Again, please advise. >> > Chris, just post the output of ./autogen.sh && ./configure && make and > then I can tell you more. Most likely you are missing a dependency or two > (like libsdl2-dev and similar). > > -- > http://mikro.atari.org > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... > https://lists.sourceforge.net/lists/listinfo/atari800-users > |
From: Miro K. <mir...@gm...> - 2024-11-18 07:50:52
|
On Mon, 18 Nov 2024 at 01:41, Chris Chiesa <chr...@gm...> wrote: > Again, please advise. > Chris, just post the output of ./autogen.sh && ./configure && make and then I can tell you more. Most likely you are missing a dependency or two (like libsdl2-dev and similar). -- http://mikro.atari.org |
From: Chris C. <chr...@gm...> - 2024-11-18 00:40:48
|
Back circa 17 May 2024 (Vol 127, Issue 8, of this digest) I popped in here, as I do from time to time, either months or decades apart, to once again touch upon the subject of building *atari800 *from source. Despite having had a Windows 10 desktop PC since January 2021, I have not yet been able to cobble up the toolchain and knowledge to build *atari800 *there -- and as Windows 10 is now on Microsoft's chopping block, and I refuse to use any newer version of Windows, I am redirecting focus onto Linux. I managed to download the source package of *atari800 *v5.0.0 onto Linux Mint (don't know what version, or how to find out) some months ago, but, alas, it fails to build. After first having to install *autoconf *to get *autogen.sh *to run at all, running *autogen.sh *produces numerous messages to the effect that various things are obsolete and I "should run *autoupdate*." Running *autoupdate* and re-running *autogen.sh*, I seem to get *fewer *complaints, but I still get them, including the advice to "run *autoupdate*". Please advise. Somewhere in the course of all that, I also get messages to the effect that I should consider doing one or another thing a particular way "when modifying my code" to make it build, but I have no idea what that's about. Just FYI. On the plus side, these efforts *do *build a *configure *file, the running of which completes without any obvious errors. Running *make, *however, then produces lots of errors, eventually enough of them of sufficient severity to terminate the build. Errors include but are not limited to flagging fundamental functions such as *close() *and *write()* as "missing," in a couple of places, as well as several much more cryptic complaints I can't make head or tail of. Investigation reveals that I don't have the X11 development materials (whatever they consist of, in this environment) for instance -- but it also isn't clear, in 2024, that these are even really what I want, anymore: for example, does SDL or equivalent exist on Linux? That seems a more efficient way to access the hardware and get better performance. Or do I need X11 for basic window-opening etc. even if I *also *use SDL? How do I set this all up? I don't even really know if any of these are the root of the problem; I mean, missing *close() *and *write()* seems like something much more fundamental is going wrong. Again, please advise. If it is no longer possible for mere mortals to build *atari800 *on consumer-grade hardware running casual installations of consumer-grade Linux distros, I might be okay with that: I'd be willing to give up the life goal of "building *atari800 *from source, someday," as age is slowly forcing me to give up various other things. It'd be depressing, but I'd live. So -- are there pre-built, Linux-on-Intel, binaries of *atari800,* downloadable somewhere? There must be, as I seem to recall downloading-and-running one, once, back when I ran Linux Mint only from a LiveCD, but I can't remember how or where I found it. What versions are available, and from where? I would be willing to use any version from v2.2.1 up to whenever keyboard handling was mangled (as also discussed around Vol 127, Issue 8, and somewhat before that), or any version at-or-beyond where that was *fixed *after I reported it. I haven't tried these later versions at all, even on Windows, where I still run v2.2.1 just because "it works and I'm used to it." Thanks in advance. Chris Chiesa |
From: Petr S. <pst...@so...> - 2024-07-15 05:17:11
|
-------- Forwarded Message -------- From: Alfred Anthony Scudiero <pat...@pr...> To: pst...@so... <pst...@so...> Subject: Atari 800 Emulator for 3DS Date: Mon, 15 Jul 2024 00:00:05 +0000 Hello friend. Thank you for taking the time to read this. The original Atari 800 was my first computer and I have had a lot of fun re-living those days with your Emulator for the 3DS. I am hoping you are still making improvements as there are two features I would love to see in upcoming revisions; Trackball and Paddle support. Using the touch screen on the 3DS, games like Super Breakout and Centipede would be great using these periferals. Perhaps assigning an area at the top or bottom of the touch keyboard to maintain the current layout. If you have a donation page I might be able to afford a contribution. Thanks again! |
From: wojciech S. <w.s...@up...> - 2024-06-03 10:05:46
|
<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div class="default-style" style="font-size: 12pt; font-family: book antiqua,palatino; color: #000000;"> maybe instead of determining the cursor position for the mouse, determine the position as it is in Windows Horror, e.g. the center of the screen or the upper left corner. Now you can count the steps, e.g. 6 to the right and 7 down, and you know where the cursor is (i.e. return to the first mouse with the trackball). unless you want a paddle from a.i, build to Atari aware of its location ;) </div> <div class="io-ox-signature"> <p class="default-style" style="font-size: 12pt; font-family: book antiqua,palatino; color: #000000;">WOJCIECH SABALA </p> <p class="default-style" style="font-size: 12pt; font-family: book antiqua,palatino; color: #000000;"> </p> </div> </body> </html> |
From: Petr S. <pst...@so...> - 2024-06-03 08:01:58
|
Hi Ralph, just a related info: I've been working on a new generation of my Dual Joy USB adapter https://joy.sophics.cz/dual-joystick-usb-adapter/ and I plan on adding paddle support this time as well. Haven't had much time lately but hopefully will get to working it again sometime soon. Petr Dne 2024-06-03 09:02, Ralph Uhl napsal: > Hello Everyone, > > I love the emulator, just one tiny little thing I would really love > to have: > Use my old original paddles with the emulator.... > > So basically I can build a little hardware box that translates the > pot positions to joystick inputs - I have also done this to act as a > mouse, however I keep getting problems with the absolute positions of > the pot and the fact that I can only send relative coordinates - I can > either only use a small portion of the turns reliably or I have to > recalibrate the positions by sending a bunch of left or right moves to > get the position in the emulator right again. > > So if someone could point me in the right direction how to map the > paddles of the emulator to joystick input of the host machine instead > of mouse movement that would be awesome. > I could easily provide Joy3 and Joy4 from the hardware side, or - > Joy1 and 2 - it is also possible to provide both paddles as 2 Axis of > Joy1.................. the real hardware also either had one joystick > OR 2 paddles > > I am not a hardcore programmer but can normally make my way to adapt > code. I checked the input.c but think I am missing something (a lot) > > So anyways any hint is appreciated, > > Ralph > > > _______________________________________________ > Atari800-users mailing list > Ata...@li... > https://lists.sourceforge.net/lists/listinfo/atari800-users |
From: Ralph U. <in...@r-...> - 2024-06-03 07:14:53
|
Hello Everyone, I love the emulator, just one tiny little thing I would really love to have: Use my old original paddles with the emulator.... So basically I can build a little hardware box that translates the pot positions to joystick inputs - I have also done this to act as a mouse, however I keep getting problems with the absolute positions of the pot and the fact that I can only send relative coordinates - I can either only use a small portion of the turns reliably or I have to recalibrate the positions by sending a bunch of left or right moves to get the position in the emulator right again. So if someone could point me in the right direction how to map the paddles of the emulator to joystick input of the host machine instead of mouse movement that would be awesome. I could easily provide Joy3 and Joy4 from the hardware side, or - Joy1 and 2 - it is also possible to provide both paddles as 2 Axis of Joy1.................. the real hardware also either had one joystick OR 2 paddles I am not a hardcore programmer but can normally make my way to adapt code. I checked the input.c but think I am missing something (a lot) So anyways any hint is appreciated, Ralph |
From: Jerzy K. <jer...@po...> - 2024-05-30 21:45:37
|
W dniu 30.05.2024 o 22:24, Miro Kropáček pisze: > I have pulled your changes and cleaned up your commits a bit (with > retaining your authorship of course). Please test both scenarios on master. It works correctly, thanks a lot! > Many thanks for your contribution! Have fun :) Jerzy Kut |
From: Miro K. <mir...@gm...> - 2024-05-30 20:24:46
|
On Tue, 28 May 2024 at 18:12, Jerzy Kut via Atari800-users < ata...@li...> wrote: > I made all changes in shift_help branch of my fork of Atari800 > https://github.com/mono6502/atari800/tree/shift_help and can create pull > request if you'd like to integrate it with main code. > I have pulled your changes and cleaned up your commits a bit (with retaining your authorship of course). Please test both scenarios on master. Many thanks for your contribution! -- http://mikro.atari.org |