Jump to content

Getafix

Members
  • Posts

    32
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Getafix

  1. Hi,

    I just updated to iOS15 but I think you made changes to the site and it's not iOS15. 

     

    I don't see the "mark sit as read" anymore on my phone in Safari. Specifically this is when I go to Unread Content which is where I usually land when I come to this site. 

    That's it - that's my whole report. 

    Thank you. 

  2. 1 hour ago, BruceMcF said:

    You really need to define "the itch" here. The "itch" here is to have a real live 8bit computer running a real live 8bit CPU. That's what defines the "willing to spend in excess of $200 on it" segment of the market.

    I think we can argue over a lot in part because there is no certainty about what's to come but I'll explain what I meant when I wrote this.  Perhaps best explained as a sequence of events that I think will unfold. 

    The Commander X8 will become available and people will post their unboxing and experiences.  That will make more people buy it (also, a bird in hand is better than 2 in the bush - the CX16 is in uncertain territory till the finances get settled so may as well get the X8 now).  Then, those of us that have made software for the CX16 will convert our software to run on the CX8, and go on to write more software for it.  Soon, there will be more X8 software than CX16 software.  When the CX16 finally becomes available, will it make financial sense to buy machine that's slower but has more RAM and isn't compatible with all the software now out there? (this all depends on how long it takes to come out, of course).  I think for many the answer would be no.  For some the answer would be yes - those that care about the fact that the machine isn't all FPGA or maybe want to build the kit or can afford both and see value in the CX16.  It will also absolutely sell less than if the X8 doesn't exist (if only by 1 - me) - and this is more true if the CX16 is only in kit form.  Retro computers are loved for their look and feel along with their inner workings.  A kit computer just doesn't have that same identity.

    Obviously I made assumptions and as the facts cement it could alter the script but for now I think the CX16 launches later, probably as a kit or maybe as a somewhat expensive ready to go system and the above narrative plays out.

    Speaking just for me - If the X8 launches, I'll buy it and be done.  If the X8 doesn't launch, and a CX16 ready-to-go launches, I'll try to buy that if I can afford it.  I don't make the distinction between all FPGA and partially FPGA.  It's real, it's hardware and I can make something for it.  It's not a simulator or emulator.  What I make runs exactly the same for all others that have it - unlike on an emulator.  I am not a collector that want's something to display only - I want to use it and share my experiences with others that use it and the X8 will do all of that nicely at a low cost allowing more people in the ecosystem and that works for me.

    • Like 2
    • Thanks 1
  3. 9 minutes ago, John Chow Seymour said:

    I don't know that you have to worry about 'fragmenting' the user base. In particular, the idea that people will now only program for the X8 as the 'lowest common platform' doesn't really apply in a situation where the software isn't being made commercially anyway.

    My guess is that people will code for both the X8 and the X16 because they're both fun to code for.  If the community is split between the two, it's not necessarily bad, it's just the community enjoying more cool stuff.  (So, keep the X8 as awesome as possible and leave at full speed!)

    I believe people are very price sensitive. If you get the X8 now for under $50, it scratches the itch.  How many people will spend a lot more later for the X16 when the X8 runs most of the software?  

    I think the X8 will inevitably cannabalize the X16 market, probably killing the X16's chances.  In the big picture, maybe that's not really a problem anyway?

  4. It definitely works as I have used it.  I am sorry I can't be more helpful right now and assuming you have r0, r1 and r2 set up, I don't see anything clearly wrong (I don't know if r2 is safe to use as your own index when calling GRAPH_put_char but I assume you checked that already).  All I can say is it does work.

  5. 2 hours ago, m00dawg said:

    Yes indeed! I got SUPER nervous when Dave nixed the X16 port of PETSCII Robots.

    That was a particularly odd choice on his part.  He could rather have cancelled all other versions and stuck to this, for the good of the project.  Perhaps he doesn't really feel this is his computer anymore, or he doesn't realize that as the father of the project, abandoning your child will look terrible in the eyes of the community.  I would call this his biggest blunder to date - at least from my POV.

  6. 9 hours ago, paulscottrobson said:

    I wrote something like that for the BBC Micro 35 years ago, to teach multiprogramming concepts, except it was basically Galaxians (it was a BBC Micro !), though it was much less complicated , more of a script processor than a mini computer. Was great fun though 🙂

    I got a BBC Micro not long ago.  Other than replace the capacitors to bring it back to life, and a little Basic coding, I haven't done anything with it.  I do want to make a game for it though.  For some reason there's no cc65 support for the BBC Micro.  I was also thinking that working on adding that support may be a good thing.  The fact that it doesn't have support does make me wonder if it may be harder than I imagine. 

    I could easily make this runtime run on the BBC and it's not really tied to SHMUP games.  Maybe when the time comes I'll think of something where I can repurpose this for some other 6502 based systems - I want to try and get some game I made on a lot of these.  I love learning how they all work.  I was astonished at how awesome the Atari 800 is technically, given it came out in 1979! 🙂

  7. Hi,

    Here's a video that shows the relatively early Shoot 'Em Up Engine I am building for the CX16.  In the engine, enemies are scripted, and the enemies are active objects with program counters, stack pointers, local memory, etc. all in a cooperative multi-tasking environment.  There's still quite some way to go before I am ready to make an actual game with this, but so far, it's looking really promising.  Iteration time for building things is very quick and I love the idea of giving designers, musicians and artists the tools to do what they do (partly because I can't do that stuff ;)

    Thank you

    Stefan

    • Like 6
  8. Instead of .org $22 just use .zeropage.  Here's a quick discussion about this: https://www.cc65.org/faq.php#ORG

    I don't use .org at all.  I use .code for the code and I do use .data for variables and .rodata for read-only data (not enforced, just the way I like to organize stuff).  Then it's all nice and neat and the linker puts it where it needs to go.

    here's an example (I saved as main.s):

    .zeropage
    myzpptr: .res 2
     
    .code 
        lda #<mystring
        sta myzpptr
        lda #>mystring
        sta myzpptr + 1
        ldy #0
    :
        lda (myzpptr), y
        beq :+
        jsr $ffd2
        iny
        bne :-
    :
        rts
     
    .data
    mystring: .asciiz "hello, world!"

     

    now compile with:

    cl65 -t cx16 -u __EXEHDR__ main.s -C cx16-asm.cfg

    and you will have main that you can run in the emulator with:

    x16emu.exe -prg main -run

    The -u __EXEHDR__ creates the basic stub (the sys 2061) for you.

    It's all very neat 😀

    • Thanks 2
  9. The Apple II emulator, AppleWin, counts the cycles of a "step" and shows it on-screen along with the registers, etc.  You can step over a line, routine or run to a breakpoint and you can see exactly how many cycles that took.  It's really great for profiling code.  That's one area where x16emu could get a lot stronger - better debugging tools.  Even with final hardware, having the ability to debug and profile in the emulator will be awesome and will lead to better quality software.  Hopefully, over time, x16emu keeps getting features such as that.

    • Like 2
  10. A couple of reasosn it looks like it does.  I was trying to use the CX16 APIs as much as I could (this was also a learning exercise for me).  The grid markers are drawn using the  Graph Put Char API, which uses GEOS fonts.  If I remember correctly, the put graph char API uses a proportional font, which is not what I needed for the menu or the move log.  The Console API did use a mono-space font but the API wasn't well suited to how the menu code wanted to work, so I ended up using the regular text in Layer 1 for the menu and log, and the graph API to put the grid markers into Layer 0.  

    I think you can add your own GEOS font for the Graph API but I don't know anything about GEOS so I didn't explore that route any further.   Also, if I remember correctly, the built-in (regular text) font on Layer 1 is a little too wide to look nice when used as a grid marker.

    When I look at the screenshot now, it doesn't look great.  It's probably worthwhile looking into GEOS fonts and making or finding a font that works for all cases.

    • Like 1
  11. I did spend a bit of time looking at the "engine" and as I suspected, there are bugs for sure.  Casteling can cause grief and corrupt the DB, for example.

    It may be worth my while to fix the bugs but I think I'd really like to rewrite the whole engine and just keep the interface to the UI (and thus have all the versions still work), now that I have been shown some chess programming resources.

    I don't need the game to be great, but it would be nice if it could play a fairly descent game of chess. 

    I am just busy with a couple of other things so I think I'll just leave it as is, for now. 

  12. I just typed this in:

    .code
        lda #8 
        tax
        tay
        jsr $ffba
     
        lda #$a
        ldx #<filename
        ldy #>filename
        jsr $ffbd
     
        stz $0
        lda #$70
        sta $1
     
        lda #0
        ldx #0
        ldy #$90
     
        jmp  $ffd8
    filename: .byte "bankxx.prg"

    I compiled with cc65 using: 

    cl65 -t cx16 -u __EXEHDR__ cx16.lib .\save.s -o save.prg -C cx16-asm.cfg

    I get BANKXX.PRG in the folder where I have the code (save.s), by using the command line (windows Powershell)  

    ~\Games\CX16\x16emu.exe -prg .\save.prg -run

    I tried omitting the setting of x and y before calling SETLFS and it did not work.  I know 1 and 0 worked, but 8 and 8 also worked so something of what @Greg King said made sense, but it's not quite arbitrary?  I will stick with a/x/y 8/0/1.

  13. Same code works for me in r38 but I have the SETLFS parameters like this (a/y reversed from how you have it):

    (for completeness - I also call SETNAM before SETLFS)

        lda #$00                                    ; logical number
        ldx #$08                                    ; device 8
        ldy #$01                                    ; secondary address
        jsr SETLFS
    • Thanks 1
  14. The ID's are 0-127 left to right (I assume the IDs are the $FC00 + ID indicies?).  The sprites are indeed 64x64 4bpp, and there are 10 on a line, yes.  @StephenHorn I attach the basic file that poke's the data and shows the sprites, if you feel inclined to check it out further.  If not, not a problem - I will assume there's an emulator issue which causes the delayed (onlines with 20 sprites) clipping and inconsistant results on a line by line basis.  At least till I learn otherwise 😉

    sprites.bas

  15. 2 minutes ago, StinkerB06 said:

    The VERA has a limited amount of time per scanline to read from the sprite attributes and place them in the buffer.  If the sprite renderer caps out at ~801 work units on a given line, then nothing else will be rendered, hence the missing sprites there.

    Sure.  What I am asking is why is it happening only on a few of the scan lines and not on all patterns that are exactly the same?  Sprite rows 3,4 & 5 are repeated at rows 9, 10 and 11, but those rows do not exhibit the same behaviour.  Is a work unit counted on a per scan line basis, or does it not neccesarily start at the left edge of the screen, at the start of a scan line?  If it is the latter, then is there a way to know how it works (counts work units)?  If the former (does start at the start of a scan line at the left) then why does it only run out of work units, sometimes?

    • Like 1
  16. Hi,

    I am playing around with sprites.  I am drawing 128 4bpp sprites in interleaved rows of 10 - using BASIC.  What I see are the sprites 40-49 being clipped badly, along with some other ones.  If I only draw 30-49, I see the same clipping.  However, if I start drawing at 31, then 40-48 are correct, but 49 is still clipped, but in a different way.

    I don't really see this being a sprite work unit issue, because it should then happen consistently across other scanlines as well, or is there something I am not understanding?  Just a bug in the emulator?

    drawing 0-127. 20 clipped, 40-48 clipped and 49 mostly missing. 59 clipped, 69 clipped, 79 clipped and 118 clipped.

    sprites.gif.50b52b33cbc5a799844d870f69fe1f55.gif

    Drawing 30-49. Same result as drawing all 128 sprites.

    image.png.49057801722a3fdb9b243dc3af181698.png

    Drawing 31-49. 49 now half visible.

    sprites1.png.1adc9e56d5bbd91cc800489e37638bbc.png

    Thanks

    Stefan

  17. Unrelated to the Pyra - I have an RG350 handheld which I love!  It’s affordable and works amazingly well. Twin sticks, 4 shoulder buttons, d-pad, ABXY, start/select and now HDMI out. Plays arcade Games (mame - portrait and landscape), NES/snes, PS1, Genesis, Dreamcast, DosBox, C64, ZX Spectrum (clever key to button mapping makes quite a lot of games work), etc.  It’s solid and beautiful. Open source so lots of Emulators and upgrades to download.  Highly recommend for anyone wanting an all-in-one retro handheld. 

    • Like 2
  18. Issues I had with adding a download file.  After adding a game, the second game I added, the "About this file" section was already (auto) populated with the text from the 1st Game I added.  Also, when I typed the first line, the font of that 1st line was different from the font of the following lines.  I didn't see font controls so I couldn't fix it.  I then pasted in some plain text, over that first line, and all of that text was now in the "1st line font".   The paste was after I closed my browser and came back to the site and chose to edit my upload. So, the font anomaly is sticky to the field.

    Otherwise, a smooth and easy experience 🙂

    • Like 1
×
×
  • Create New...

Important Information

Please review our Terms of Use