Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

hawk

Members
 View Profile  See their activity

  • Content Count

    61

  • Joined

  • Last visited

Posts posted by hawk

  1. Posted

    7 hours ago, kbr said:

    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...

    @kbr I'm assuming that you're aware of this guy's work with MCUFriend TFT panels and Arduinos. https://github.com/prenticedavid/MCUFRIEND_kbv/blob/master/extras/mcufriend_how_to.txt

     

    I wouldn't go a look there if I were you...it will scare you the number of variants he has identified.

     

    This seems like good info though...

    Quote
     
     

    12. These Mcufriend-style shields tend to have a resistive TouchScreen on A1, 7, A2, 6 but are not always the same rotation of direction.

    The TouchScreen_Calibr_native.ino sketch wiil diagnose Touch Pins, do Calibration, report to Serial Terminal.

      The Calibration should work with the TouchScreen.h library from Adafruit.
      You can always copy the local TouchScreen_kbv.h library from sketch to the global user libraries folder.
     

    BTW, what platform do you develop SDrive-Max firmware on?

    I can build easily on OS X, however on windows, when I used WinAVR, I got compilation errors associated with PGM_P.  When I went to AVR Studio 6.? I got it to compile, but haven't yet tested the new binary.

  2. Posted

    On 7/17/2019 at 5:36 AM, kbr said:

    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 :)

     

    This screen doesn't work with the current software. (1.2b)  It displays correctly (You can see the sticker for 8347 on the bottom), however the touchscreen does not function correctly.

     

    With one of the builds it was detected by the software, however the touches were not where they were supposed to be.  I think I worked out that the touches were rotated 90 degrees, indicating that the X and Y inputs were swapped.  Based on this, I guess it should be an easy fix.  Back then I was not able to compile my own firmware.  Maybe I'll give it another go.

     

    These screens are a lot cheaper than the 2.8" ones...about 1/3 the price. ($6AUS).

    IMG20190719150110.jpg

    IMG20190719150127.jpg

  3. Posted

    7 hours ago, Kyle22 said:

    I didn't see any binaries in there. Has a compiled version been released?

     

    I compiled my own binaries.  I haven't been able to do this easily in Windows (I get compilation errors) but it compiled on OS X using CrossPack for AVR.

  4. Posted

    12 hours ago, NISMOPC said:

    Great news! I might have to give it a test run for my extra TFT screen and R3 board.

    Yippee...It works.  My cheap 2.8" ID:4747 TFT works.  I looked at the changes and they looked pretty much the same as what I tried.

     

    The cheap 2.4" MCUFriend TFT that also has ID:4747 didn't work.  It displayed correctly but the touchscreen didn't detect.  I have a suspicion that the touchscreen interfaces the same as one of the other models, but the orientation is 90 degrees out, not 180.

     

    Now I just have to wire up the rest of the SDrive-Max...

  5. Posted

    Hey NISMOPC,

    I am in the same situation.  I have purchased a cheap 2.8" screen that has TFT ID:4747 that I figure is also a HX8347-D.

     

    When I loaded the HX8347-G firmware, the display was correct, but the touch screen didn't work.

     

    When I loaded the HX8347-I firmware, the touchscreen worked, but the display was mirrored horizontally.

     

    These results led me to believe that it was possible to get this display working, so I built my own firmware version for HX8347-D, choosing the -I display options and the -G touchscreen options.  I didn't work.  It functioned the same as the -G version.

     

    I can't find the options for the display that differ between the -I and -G versions.

     

    Any help would be appreciated.

    Hawk

  7. Posted

    OK, so a bit of research tells me that the biggest issue to overcome in making your own replacement keyboard is the physical size of the keys.

     

    The standard 400 membrane keyboard has spacing on about 15mm centres. Modern keyboards are 18mm keycaps on 19mm centres.

     

    I guess that's why aftermarket keyboards had to come up with the alternative layouts.

     

    I found that Cherry ML keys switches (~12mm x 12mm) would work for spacing, however you would need modified or custom keycaps, as I was unable to find any miniature keycaps. I guess it would be possible to 3D print keycaps these days.

     

    My eeePC 701 has key spacing the same as the 400 and it feels really tiny. Why didn't the 400 ever feel that small. For me, back when it was my only computer, it was the membranes that were yuk. I didn't even notice the key spacing...but then I wasn't trying to touch type either.

     

    Hawk

  10. Posted

    I wanted to follow up with the outcome of this repair.

     

    Replacing the RAM chips worked fine. I now have another working XEGS. I got it hooked up with a disk drive and an SIO2PC and its great. Maybe I'll look at what other mods I might be able to make to this one.

     

    I noticed on this http://atariage.com/forums/topic/258497-xegs-hints-for-repair/ thread mikro was having a similar problem, although his screen appeared differently to mine. I will now go and check out my power supplies to see that they're not causing the problem.

     

    Thanks very much for your assistance.

    Cheers.

    • Like 1

  11. Posted

    Thanks very much for the replies. It gives me hope that I'll be able to get it up and running as soon as the IC sockets arrive. I'm hoping that the speed of the RAM chips isn't super critical, as I'm using some 100nS ICs from an old video card.

  12. Posted

    I finally got a round 'toit' and started having a go at repairing a non-working XEGS that I bought a few years ago. The two RAM chips were running very hot, so I've started by removing them. While I'm waiting for the new IC sockets to arrive so I can continue the repair, I thought I'd ask what to expect if I turn the machine on without any RAM?

     

    Aside from the RAM chips running hot, the other symptom I have is a black screen, and this got me wondering whether the RAM test would run at all if the RAM wasn't installed, and that I've actually got another fault as well that will need new another new chip.

     

    Any ideas?

     

    Thanks,

    Hawk.

     

  13. Posted

    Is anyone using an "Atari" game-pad, or any other game-pad which requires modification and/or an adapter?

     

    I'm using rewired NES game pads. I find game pads easier to use in many cases these days.

     

    I do remember, in my youth, playing Crossfire on my Atari 400 for so long that I had to wrap a tea-towel around my hand to reduce the pain from the CX-40 joystick digging into my hand.

  14. Posted · Edited by hawk

    This sounds very similar to the problem I had with my XEGS. I diagnosed it to leaky capacitors in the power supply. Since the power supply was potted, I had to scrap it and use an alternative one. I'm now using a Commodore Amiga one.

     

    To test this theory, try powering your system from a bench supply with sufficient current rating and see if the problem goes away.

     

    I hope this helps,

     

    Cheers

    Mike.

  16. Posted

    Hi Gury,

     

    I had a play with some mode 5 characters, and they looked OK, but I've been playing with...VIC-20 stuff lately. Then I look at the size of the task I want to undertake and realize that I have to set my sites lower, or I won't complete anything. Retro computing is one of my many hobbies (not including my family), and within it, I'm interested in many platforms. Even restricting myself to one CPU type is difficult!

    However, the Atari 400 was my first computer, so it always has a place in my list of hobbies.

  17. Posted

    In theory, couldn't you combine several resistors on seperate switches for multiple inputs on the one paddle port?

     

    Values would have to be chosen carefully so that multiple keypresses could be detected.

    The link I gave shows how to connect two Normally Open switches to a single POT input. The circuit is complicated by the fact that most joypads use Normally Open switches. You can see that if a Normally Open and a Normally Closed switch is used, the circuit is greatly simplified.

     

    When the Paddles are read from BASIC, is the delay still required, or is all thet handled by the BASIC routine? Maybe a BASIC program would be the easiest way of testing the operation of the switches.

  19. Posted

    Well I finally got hold of a CRO, and was able to diagnose this problem further. It turns out that you were right on the money A.J. It was the "Wall Wart". (Although it's not actually a wall wart in this case...more like a C64 potted power supply) I powered the machine from a 5V bench supply and the display was perfect.

     

    Thanks for the advice A.J.

     

    Now to look for a suitable replacement power supply. I'm looking in to using a PC power supply to power the XEGS, the XF551 and the 1010 Program Recorder. I've seen how you can add a dummy load to keep the switch mode power supply happy.

     

    Mike.

  21. Posted · Edited by hawk

    :!: Warning: Long Reply :!:

    I don't have a lot of experience in this area yet, but I thought I'd let you know what I have learnt after getting an Antic 4/5 concept demonstrator working.

     

    I prefer to declare my screens, display lists, DLIs and VBIs in an assembler file and export them. Then via a C header I use them in the C code.

     

    I then create a custom linker config file to align the segments to the appropriate place.

     

    Advantages of this method are that address references can be used when declaring the display lists, which are then resolved at link time. This means that the display list, screen and DLIs can all be moved around within memory without having to update the display list. This results in improved maintenance and understandability. (Two important points in my job as a Software Engineer.)

     

    .export _screen
.export _dlist
.export _dlist_data
.export _dlist_next
.export _dli

.segment "DATA2"
.align $100

_newfont:
.include "myfont.fnt"

_screen:
.res	40x24, $00

_dlist:
	.byte 112, 112
	.byte 68
_dlist_data:
	.addr _screen	; Adreess memory screen
	.byte 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
	.byte 4, 4, 4, 4, 4, 4, 4, 132, 132, 4, 132, 4, 4, 4, # (5) 25 lineas Gr.12
	.byte 65
_dlist_next:		
	.addr _dlist

_dli:
<do something>
rti

     

    If any of the dlist lines calls my dli, all I need to do is add the 

    .addr _dli

    declaration in the display list. I also plan on replacing the display list numbers with a more meaningful declaration, again to aid clarity.

     

    As you can see, the initialisation required to setup the display list has gone. All I need to do is point to the new display list from C.

     

    The C header contains the following

    extern unsigned char screen[40][25];
extern unsigned char dlist[32];
extern unsigned char* dlist_data;
extern unsigned char* dlist_next;

    Keep in mind that all these extern declarations in C cost no additional storage space, as that is already declared in the assembly file.

     

    Creating interlaced display lists is also very easy using this method. Just declare another display list and set the last address of the first to the first address of the last, and vice versa.

     

    One really big disadvantage of this method is that if you are trying to create a really small footprint for your program, you will find the space between the and of one segment (eg. code) and the start of the aligned data segment padded with zeros.

     

    Perhaps it is possible to declare the data at the start of the program, and the code at the end. The code could then butt up against the the end of the data. Someone else may know the answer to this question, I haven't tried it yet.

     

    The linker config file then looks like this

    MEMORY {
ZP: start = $82, size = $7E, type = rw, define = yes;
HEADER: start = $0000, size = $6, file = %O;
RAM: start = $2E00, size = $8E20, file = %O;	# $8E1F: matches upper bound $BC1F
}
SEGMENTS {
EXEHDR: load = HEADER, type = wprot;
CODE: load = RAM, define = yes;
RODATA: load = RAM, type = wprot;
DATA: load = RAM, type = rw;
DATA2: load = RAM, type = rw, align = $1000;
BSS: load = RAM, type = bss, define = yes;
ZEROPAGE: load = ZP, type = zp;
AUTOSTRT: load = RAM, type = wprot;
}
FEATURES {
CONDES: segment = RODATA,
	type = constructor,
	label = __CONSTRUCTOR_TABLE__,
	count = __CONSTRUCTOR_COUNT__;
CONDES: segment = RODATA,
	type = destructor,
	label = __DESTRUCTOR_TABLE__,
	count = __DESTRUCTOR_COUNT__;
}
SYMBOLS {
__STACKSIZE__ = $800;	# 2K stack
}

     

    pokew(dlist+3,pantalla);

    pokew(dlist+30,dlist);

    *(unsigned char *) SDMCTL -= 32;

    pokew(560,dlist);

    *(unsigned char *) SDMCTL += 32;

    Personally, I prefer to not use poke and pokew commands. These can be replaced by C equivalents which are just a single assignment.

    #define DLIST		(*(unsigned char*)560)
...
  DLIST = &dlist;		/* Setup to use my new display list. */
...

     

    I thinked in this way my screen memory was safe. But the garbage appear when I add code in my program. The monitor shows the reserved screen area ("pantalla") was fine, but the emulator screen show another thing.

    For this problem the screen data or character data (I can't tell which right now) is probably crossing a 1k/4k? boundry. Setting up the linker config file to align the data to the appropriate boundry should solve this.

     

    I'm still working on my planned Console RPG, which hopefully will demonstrate the techniques I've discussed here with plenty of comments. Much of this I've learnt from all the examples of both CC65 and straight assembler code that people have kindly made public. As a result, mine will also be public...just so people can see where I've reused their ideas. ;)

     

    Mike

  22. Posted

    As well as the samples that come with CC65, there is some good coding examples for the Atari 8-bit platform put into the public domain by a few of the guys on this forum.

     

    Check out the Jellybeans source code and the Greed source code. With these examples, I found that it didn't take long to get a demo together that used re-defined character graphics, and DLIs. Beef Drop also uses the CC65 suite, but is pure assembly code. One of them has an example of how to hook RMT in for music.

     

    But I'd have to agree with Heaven. Programming for these older 8-bit machines, even in C, is a lot more like embeded programming than application programming. It's important to know what sort of assembly code the CC65 compiler is going to create. For me, this is half the challenge...write C code that is efficient, even on an older platform.

     

    Just my 1.03c worth (2c less tax not including GST)

  23. Posted

    Sniping is the only way to go to get the good deals. ;)

     

    To the guy bidding 10k to ensure an auction win, better hope no one else gets that same idea. :)

     

    ~telengard

     

    This looks like an example of exactly what you're talking about. :)

     

    Snipe gone wrong!

     

    What's the bet that the guy who won it defaults on payment? (Maybe he's reading this right now ;) )

  24. Posted

    Yea, took me years to track down a variant of that console for my 'i must have every format of game console made' collection. But I've never even once fired up the thing.

     

    You don't by any chance have a BASIC cartridge for it that you don't want?

     

    I bought one because it was my wife's first computer. But without a BASIC cartridge, all I can do is play the few games that we have on cartridge.

    • Like 1

  25. Posted

    Atari_Kid, I can understand where you're comming from wanting to play the games on the original system for which they were intended. Hell, that's why I have so many retro computers in my shed. I even considered getting a GBC for my son, since you can pick them up reasonably cheap.

     

    But when it comes to practicallities of gaming on the go, you just can't go past the GBA SP. The bright clear screen...the folding design...the lithium rechargable battery. I've had mine for a couple of years, and was even starting to aquire a few classic GB/GBC games to play on it, but like you said, the carts hang out the bottom.

     

    I've had a Flash Cart since I first got it, mostly for playing with developing for GBA. Then I discovered the GB emulator for GBA. I'm now enjoying playing those GB games that I missed, without having to lug carts with me. My current favorite flash cart take SD cards, so I have a 512MB SD card. That holds a lot of games. I've also just started to check out some of the Game Gear games via emulation. I find the emulators that try to handle the TV resolution to be too ugly, so I'm sticking to the portable formats.

     

    Anyway, if you really must have the original machine, I'd go for the later design. It sounds like it has a clearer display.

     

    Good luck with you desicion.

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...