kbr
Members-
Posts
51 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Community Map
Everything posted by kbr
-
This is for XEGS users, who don't have a keyboard, i think.
-
I think this is a long filename issue, the search only shows on the DOS(8+3) filename.
-
sdrive SDrive-Simple - Yet Another Hardware Variation
kbr replied to mytek's topic in Atari 8-Bit Computers
The thing is, if long file support is turned on, then the sdrive control program is loading from SD card on each file selection. Otherwise only on assign, change directory or other options which need disk access. -
sdrive SDrive-Simple - Yet Another Hardware Variation
kbr replied to mytek's topic in Atari 8-Bit Computers
I don't see any dependency to long file name support, but i have to try it by my self next days... I have no long time experience with the display, the screen blanker is originated more than a nice gimmick You have to change the default value for the cfg byte in eeprom at tft.c from 0xf3 to 0xe3 i guess: unsigned char cfg EEMEM = 0xf3; //config byte on eeprom, initial value is all on except boot_d1 and 1050 -
sdrive SDrive-Simple - Yet Another Hardware Variation
kbr replied to mytek's topic in Atari 8-Bit Computers
I think this is caused by the screensaver, have you tried to disable "Blank" at the Cfg menu? -
The Master branch is equal to V1.2, right, the last stable version. V13 is the actual unstable development branch, a daily snapshot, if you want.
-
Why use V12c, this was a development branch only and is no more present. It may be, that in some stages the code was too big for some display variants... Use the Master branch for a clean version, or if you are risky V13 It could also depend on your compiler version, i use avr-gcc version 5.4.0.
-
First i looked at the hardware sheet, and found no difference to the key wiring, so i thought, we can take the same mappings. There is known, that on XL/XE the key table pointed on ($79)(121) is at $FB51. So i used the emulator for atari 800, and diged through the ROM, and found the same table at $FEFE, that's all.
-
np @tsom: Please try https://github.com/kbr-net/sdrive-max/blob/v13/sdrive-ctrl/sdrive.atr
-
Good catch, people who have or use a real 800/400 are very rare, unpayable :) I will keep it in mind, the input methods could have an update anyway, the OPTION key for scroll down is suboptimal in my opinion, but the atari side of programming is not my biggest goal...
-
Maybe it depends on the display type, some needs more code and time for initialization, than others. Hold down the reset key during power on until sdrive-max is ready!
-
Good idea, may need only 5 bytes/icon, but poor b/w and 5x8 resolution. I will keep it in mind...
-
Do you really think, this 5 or 6 chars more, makes the Kraut fett? Icons are no option, because icons needs much more memory, that we don't have, than simple chars.
-
This would be difficult, because the 32K flash is nearly full, and the intention of SDrive-MAX is KISS(keep it small and simple). This is not possible, because we have no screen buffer, and must draw each pixel manually. Otherwise this would be very slow on this interface with 16MHz, and we cannot make the font too small, because one should be able to select filenames with fingers.
-
there is an evil buffer overflow in SDrive-MAX, because this file has blocks with 1030 bytes, never seen before, and buffer is only 256 bytes. Try to fix this, but there is an fsk block at the end also, this is not supported. works now after fixing the buffer overflow, the fsk block does not hurt. Will be included in the next release V1.2.
-
works without keyboard input works without keyboard input there is an evil buffer overflow in SDrive-MAX, because this file has blocks with 1030 bytes, never seen before, and buffer is only 256 bytes. Try to fix this, but there is an fsk block at the end also, this is not supported. Testet on my 130XE
-
SDrive XEX Loader from SD card ? How / What's required?
kbr replied to jedimatt42's topic in Atari 8-Bit Computers
You have to flash the eeprom_writer.hex BEFORE the sdrive.hex, otherwise it could not work, then you have only the eeprom_writer in the flash. This is a workaround, because the arduino USB/serial bootloader does not support writing the EEPROM directly(with ISP you can), so i built an own program to do this just in system. I always power my 3 arduinos with display via USB and had no problems yet, because this is the easiest way while developing. I bought them all at amazon, and not the cheapest china ware. PS: You hopefully have cut the power connection to the atari, if powered via USB, otherwise you power your atari via the arduino/USB too! -
SDrive XEX Loader from SD card ? How / What's required?
kbr replied to jedimatt42's topic in Atari 8-Bit Computers
This problem sounds like the EEPROM was not fully written, because the XEX loader is in the EEPROM. It is essential to wait after flashing the eeprom_writer.hex until "Done!" is displayed! -
The latest official release is: https://github.com/kbr-net/sdrive-max/releases/tag/V1.1 In v12 there is only a beta for a firmware for HX8347D, a combination of HX8347G(screen) and HX8347I(touch), and ILI9341 with ILI9340 touch. Binary: https://github.com/kbr-net/sdrive-max/releases/download/v1.2b1/sdrive-max-v12b1.zip, https://github.com/kbr-net/sdrive-max/files/3481413/sdrive-max-v12b2.zip
-
Sure it is, the easiest way to test this, is to leave all slots empty, and select any of them, except the special slot D0:, then SDRIVE.ATR would act as D1:! Otherwise there is a hardware problem, like the other guys commented. not necessarily, this has only effect on power-up, but if SDM is powered by SIO, this may help.
-
Yes, this is a feature of sdrive* to quickly switch an other slot to act as bootdrive D1:, other drives will be renumbered respectively. Select the first slot as D1:, let them empty, and you will get all drives in it's normal order, while D1: is acting off, and so on... Empty slots are always acting as drive off/not present!
-
Thanks, there is no hint about I²C. If you have the arduino IDE installed, you can try this sketch: https://github.com/prenticedavid/MCUFRIEND_kbv/blob/master/examples/diagnose_Touchpins/diagnose_Touchpins.ino @hawkI develop on linux with avr-gcc.
-
Backside please! Oh dear, why are there so much variants in the wild... @hawkChanging X and Y should not be a big problem, but building for each variant an extra firmware will end in a mess. I am thinking about an autodetection...
-
There are also touchscreens with an I²C-Interface in the wild, for which there is no support. I don't now, how difficult and big it would be, because i have never done anything about I²C. Can you send a picture of it both sides? dict.leo.org is my best friend
-
Thanks too! I refused a long time to register here, because of my bad english, but now i could not hold off And there is much more activity, than in german forums
