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

ZackAttack

Members
 View Profile  See their activity

  • Content Count

    785

  • Joined

  • Last visited

Posts posted by ZackAttack

  1. Posted · Edited by ZackAttack

    It's pretty obvious at this point that I've done a terrible job at communicating in my first post. Please allow my to clarify some things.

     

    The term false advertising is used in a technical sense. If it turns out that this is a case of false advertising, I'm sure it was the result of an honest mistake and would never suspect anyone related to the harmony product of intentionally misleading customers. There's actually a more specific term which is used when it was intentional, but I'll refrain from using it here to avoid having it associated with the harmony product.

     

    I have no idea if the user batari is managed by a single person or multiple people involved with the product. I only mentioned that I messaged batari directly to make others aware that I tried the official support channel before posting to the forum.

     

    I have recommended this product to others on the forum in the past and will continue you to do so after making them aware of this minor potential limitation.

     

    I thought I should offer some possible solutions since I was reporting what I perceive as a problem. I never meant for this to be taken as a list of demands. After reading some of the replies I now see how this is speaking on behalf of others. Sorry about that. If and when I get permission to edit that post I will remove this portion of the post to make things right.

    • Like 1

  3. Posted

    Please provide a download to your 512kb game that you have programmed and we can go from there.

    It's attached to the other post that I linked in the original post. Omegamatrix was nice enough to make another 3E test rom, which is also attached in that topic, but neither of us have had a chance to test the harmony with his yet.

    Here's a direct link to the test ROMs.

     

     

    Maybe the 512K support is for some format other than 3E, like supercharger.

     

    Thanks. I'll look into making another 512KB test program with the Arcadia Supercharger bank switch type and report back the result.

  5. Posted

    The test roms that I originally posted use one page of RAM. So I limited it to 510KB of ROM in order to keep the total at 512KB. So I guess really it's a 34KB program that's working since the 32KB bin file is the one that worked on the harmony.

     

    I'll try the 512KB bin that you posted sometime this weekend. Btw, stella will auto detect a 3e game if you put HEX 85 3e a9 00 in the image.

  6. Posted

    I tried your 510k rom in Stella and noticed you TIA registers are normal (not offset). I believe with 3E you have to offset them or else you will trigger bankswitches. I looked and found in an old 3E rom I had done this:

    VSYNC   = $00 | $40              ; must use TIA mirror registers at 0x40 for 3E bankscheme
VBLANK  = $01 | $40
WSYNC   = $02 | $40
RSYNC   = $03 | $40
NUSIZ0  = $04 | $40
NUSIZ1  = $05 | $40
COLUP0  = $06 | $40
COLUP1  = $07 | $40
COLUPF  = $08 | $40
COLUBK  = $09 | $40
CTRLPF  = $0A | $40
REFP0   = $0B | $40
REFP1   = $0C | $40
PF0     = $0D | $40
PF1     = $0E | $40
PF2     = $0F | $40
RESP0   = $10 | $40
RESP1   = $11 | $40
RESM0   = $12 | $40
RESM1   = $13 | $40
RESBL   = $14 | $40
AUDC0   = $15 | $40
AUDC1   = $16 | $40
AUDF0   = $17 | $40
AUDF1   = $18 | $40
AUDV0   = $19 | $40
AUDV1   = $1A | $40
GRP0    = $1B | $40
GRP1    = $1C | $40
ENAM0   = $1D | $40
ENAM1   = $1E | $40
ENABL   = $1F | $40
HMP0    = $20 | $40
HMP1    = $21 | $40
HMM0    = $22 | $40
HMM1    = $23 | $40
HMBL    = $24 | $40
VDELP0  = $25 | $40
VDELP1  = $26 | $40
VDELBL  = $27 | $40
RESMP0  = $28 | $40
RESMP1  = $29 | $40
HMOVE   = $2A | $40
HMCLR   = $2B | $40
CXCLR   = $2C | $40

CXM0P   = $00 | $40
CXM1P   = $01 | $40
CXP0FB  = $02 | $40
CXP1FB  = $03 | $40
CXM0FB  = $04 | $40
CXM1FB  = $05 | $40
CXBLPF  = $06 | $40
CXPPMM  = $07 | $40
INPT0   = $08 | $40
INPT1   = $09 | $40
INPT2   = $0A | $40
INPT3   = $0B | $40
INPT4   = $0C | $40
INPT5   = $0D | $40

SWCHA   = $0280
SWACNT  = $0281
SWCHB   = $0282
SWBCNT  = $0283
INTIM   = $0284
TIMINT  = $0285
TIM1T   = $0294
TIM8T   = $0295
TIM64T  = $0296
T1024T  = $0297

    This also more properly done using vcs.h with TIA_BASE_READ_ADDRESS = $40 and TIA_BASE_WRITE_ADDRESS = $40. Also just for clarity my 3E rom was not over 32K.

     

    Thanks for taking a look. According to the kevtris blog using the TIA mirrors is only necessary for 3F. It also doesn't explain why my 32KB test program doesn't crash too. Would it be a valid test to take your 32K rom and concatenate it with itself to create a 64K test ROM? Of course if that works we could continue to double it up to 512K for testing purposes.

  7. Posted

    So if I give you a bag and say it will hold 1 million dollars, but you don't know of anywhere to get 1 million dollars, my bag won't hold 1 million dollars?

     

    If you read my post carefully you'll see that myself and others have tested with 3E bank switched ROMs which are larger than 32KB and which work in stella but do not work with the encore. So your analogy is wrong because it implies no one has ever had in their possession 1 million dollars to test with.

     

    Bad and illogical attitude. If you don't know how to make a 512K ROM work, how do you know it doesn't work? :roll:

     

    I don't know that it doesn't work for sure. However, as the other post shows, I'm not the only one that ran into the problem and I was pretty careful about how I tested it. This is a product that is specifically advertised to support it. I think it's quite reasonable that the burden of proof is on the vendor. I provided the same program with multiple ROM sizes to show that 3E games work fine if they are 32KB.

     

    And who are you to speak on behalf of other owners?

     

    That is certainly not my intention. I simply want an already good product to do everything it was advertised to do when I purchased it.

  8. Posted

    I've previously posted about getting a larger game to work on the Harmony Encore and also messaged Batari directly. There has been no reply to either.

     

    The website couldn't state it any more clearly that up to 512KB games are supported, but I have yet to find any documentation on how to make such a game or any examples of such games already existing. Does the encore really have support for 512KB homebrews or is this a case of false advertising?

     

    post-40226-0-14959600-1519960206_thumb.png

     

    I'd like to propose some potential remedies to this situation. (ordered by my preference)

     

    1. Provide an example 512KB ROM which can be run on the harmony encore.
    2. Provide a new firmware release which adds support for 512KB games. This must be done in a timely manner. My opinion is that 6 months or less would be reasonable.
    3. Open source the firmware so the community can add support for 512KB games.
    4. Provide a partial refund for all harmony encore owners with an amount similar to what it costs to upgrade form a regular harmony to the encore.

     

     

  9. Posted

    Interesting. I got those errors too, but didn't notice before because DASM keeps going and generates a working bin file for me. My build script automatically runs the bin so I don't bother looking at the output if stella pops open with a working program.

     

    The macro below couldn't be expanded in the first two passes, so it takes up 0 bytes. Then after SPRITE_HEIGHT is calculated it evaluates the REPEAT macro and causes an extra 18 bytes to be inserted into the bin, moving the location of everything after it. I've reordered things to prevent this problem. I assume you guys are using a different OS or different version of DASM, and that's why the error failed the build completely for you, but not me.

    	REPEAT SPRITE_HEIGHT
	BYTE $ff
	REPEND

    Here's an updated asm file that should build for you too.

     

    mask_draw_demo3.asm

     

    • Like 1

  10. Posted

    If you run into any more problems, please attach the asm file instead of pasting it's contents into your post. You have to use the "More Reply Options" to attach files to your post.

     

    DASM treats any line without white space as a label and wouldn't assemble what you pasted above because most of the indentation got lost. It appears as though all the leading tabs were removed at some point.

    • Like 1

  12. Posted

    I'm not sure what you mean by slice. Atari doesn't have the notion of sprites built in. It keeps drawing the 8 bit wide player graphic every line. So you create a sprite by changing the GRP0 register each line, or every other line in 2lk. The height is controlled by the software you can make the Sprite as tall as the screen if you want.

    • Like 1

  14. Posted

    Happy to help. Just for fun I went ahead and optimized for the 1LK variant. The mask only takes 256 bytes because it exploits the natural wrap around of the 8 bit Y register. Keeping everything aligned properly is critical to avoiding a 1 cycle penalty for crossing pages. So the net is a couple bytes of RAM, 150 bytes of ROM, and 2 cycles during the kernel.

     

    Of course a 2LK will consume much less ROM space for mask and graphics and single colored sprites would save a bunch of resources too.

     

     

    mask_draw_demo.asm

    • Like 1

  16. Posted · Edited by ZackAttack

    If a modern assembly language programmer doesn't use the same tools as they did in the early 1980s, all copies of his or her program should be destroyed. And the punishment for quick and easy testing with an emulator should be public flogging.

     

    I'm not sure that's severe enough punishment. Perhaps we could make a custom cart with some switches to program it one byte at a time and require them to use that for all future development. Of course it would be stored in RAM so you have to program it again if you cut the power.

    • Like 1

  17. Posted

    Some inspiration:

    S2_map_EHZ1.png

    :D

     

    You know, with bus stuffing something like this could probably be achievable. Though it would be helpful to replace rings with something that can be drawn with missiles and balls too. Like coins, bananas, apples, etc. Or ditch the smooth scrolling and it's super simple to implement.

  18. Posted

    I assumed that there would be some modules which can be mixed and matched. That's why I suggested wrapping them in header files with some sweet preproc magic to fix up the offsets of everything. Each module header would know how big it is and would calculate offsets for its symbols based on some global modules size variable after which it would increase the global modules size by the amount of itself.

     

    Regarding debugging. Users of Spice C shouldn't need to debug the prebuilt kernels. You could do what I do for strong-arm and have a special debug cart class which runs win/Linux/mac binary and then you just build it as part of stella and debug it that way. This is how I'm developing Wushu Masters. I do everything in visual studio and only bother building for ARM when I'm ready to test on actual hardware. Of course you could just as easily use eclipse, gdb, or whatever other toolchain that is capable of building/debugging stella source.

  19. Posted

    Just a thought here. Since all the 6502 code is going to be part of the framework. Why not just include it as bins which can be pulled into the C build. That way users of Spice C don't have to configure dasm at all. You build the C files and it spits out the 32KB file.

     

    It should be fairly simple to accomplish with a few header files, some preprocessor directives, and maybe some linker script magic.

    • Like 1

  20. Posted

    The playfield graphics are 80 pixels horiztonally, if you wrote an assymetrica playfield. The player sprites are 160 pixels horizontally if you were able to draw a whole scanline of them.

    So the playfield graphics are half the horizontal resolution of the player sprites.

    You meant 40 PF pixels right?

  21. Posted

    I think you might be able to mock this up in batari basic pretty quickly. It might be worth a try so you can get a better feel for the limitations of the system. For what you describe I believe the Multisprite Kernel with a HUD is what you want.

     

    If you prefer to go the assembly route you can do better graphics, but it's going to take longer to learn what you can do and how to do it.

    • Like 1

  23. Posted

    Honestly I think the fact that precise timing is so critical for the 2600, the most powerful option will always be ASM.

    With the right framework C will make programming the Atari more accessible since it'll be a standardized language that many people already know. bB is a very specialized version of basic. A VB.net programmer couldn't just pick it up and start writing a game immediately without first learning some things about the Atari. C also leaves the possibility of using more modern IDEs and having source level debugging. Little things like conditional breakpoints can be huge time savers.

     

    Honestly I think the fact that precise timing is so critical for the 2600, the most powerful option will always be ASM.

    This is no longer true. I write my display kernels in C code that runs on the ARM chip and use the time in between emulating the ROM to calculate the next few bytes of ROM on the fly. It's kind of like having a display kernel which is made up of only LDA# STA tia_reg repeated over and over, but instead of hardcoding it in ROM you create it dynamically just before it's executed by the Atari.

     

    I neither can nor will judge this (except for it being cool on its own).

    But I ask to keep in mind that BatariBasic, DPC+, ARM, etc... will (and already have!) changed people's view of the VCS.

    To me it loses a lot of its charme. Being the minimalistic console it used to be.

    'Racing the beam' (that actually along with others triggered a new hype I dare say) becomes obsolete.

    People forget about TIA, RIOT.

    If different approaches are not separated by the designers, developers and gamers the Atari VCS at its core will vanish.

    Surely you can still code in 4,8,12,16 KB and re-live the pain/challenge/excitement that VCS developers had for decades(!).

    But it might become obsolete.

    4 out of 5 new additions in the store rely on heavy additional processing power on the cartridge.

    And people out there do not know the difference. It might in fact not matter to the person who plays the game. But what about the legacy value of the VCS?

    I love what people do and what crazy ideas they actually realize but if the community as a whole is not carefully and open about it, it will annihilate what the VCS used to be.

    It pains me to see old coding heroes being degraded to noobs in youtube/facebook/forum comments because their games didnt scroll or feature large title screens.

    This is merely my personal statement, so hopefully noone is offended or feels criticised.

    I am only worried. Quite worried.

    I have this concern too and recognize that there will be people that compare a game built in 2018 with an ARM chip to a game built with only 2K of ROM back in the day. But I've also considered that someone is going to keep pushing the limits of what a 2600 cart can do. So I might as well join in with the fun and just make it a point to educate people that newer technology in the cart allows for visuals that were once impossible on the system. Besides no matter how much processing power there is on the cart, you still can't overcome the limitations of the TIA.

    • Like 1

  25. Posted

    I agree, I'm trying to decipher assembly but man it's still functionally greek to me. I've read and am re-reading the posted tutorials but it's just really cloudy.

     

    Not giving up though.

     

    You don't really need to understand much to modify the graphics in the asm. Really you just need to know how to assemble it to a .bin so you can test it. Have you tried the following?

     

    1. Open the .asm I attached in my previous post in a text editor of your choice.

    2. search for MPH

    post-40226-0-88426600-1519048751.png

    3. change the 1's and 0's to produce the desired MPH graphic and save the asm file.

    4. Assemble with dasm. There's a bunch of ways to do this. This simplest is to call dasm from the command line with the path of the asm file. On windows I use a small batch file which assembles it and then runs it.

    SET progpath=%~dp1
SET fileName=%~n1

dasm.exe  "%progpath%%fileName%.asm" -f3 "-o%progpath%%fileName%.bin" "-l%progpath%%fileName%.lst" "-s%progpath%%fileName%.sym" -v5

"%progpath%%fileName%.bin"

    but you can get away with just running

    dasm.exe  "C:\path\file.asm" -f3 "-oC:\path\file.bin"

    ​

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...