intvnut
-
Content Count
3,713 -
Joined
-
Last visited
-
Days Won
7
Posts posted by intvnut
-
-
Since I had a couple different customers email me on this topic, as recently as today, I figure I should say this as clearly as I can:
When I say I am running low on units, I mean un-reserved units.
If you've emailed me saying you're sending a check, and I've responded acknowledging that fact, your units are reserved. Even if I "sell out" before your check or money order arrives, your units are waiting for you. I will only accept orders I can fulfill.
If, for some reason, I don't receive payment for a reserved cart, then I'll eventually have to release that reservation. So far, I've never had to do that (at least that I can remember). If it ever comes to that, I'll be sure to contact the customer first to try to sort things out. It's possible mail went missing and my customer forgot about their order. It may not be likely, but it is possible. And so if it ever comes to that, I'll sort out outstanding reservations to the best of my ability before releasing them.
-
2
-
-
10 hours ago, Steve Jones said:I think they have been in Canada for a while but are caught in our backlog here, I have experienced the same delay with other shipments from the US regardless of where they originate, just seems to be how things are these days.
I wish there was at least a little transparency. At least tell us what country they're in! Sheesh. I guess they could be within the territorial boundaries of Canada. But, until Canadian Customs processes them, they haven't technically entered Canada; rather, prior to passing through Customs, they're still "outside Canada" in most legal senses. So, there's that bureaucratic detail. 🙂 (I'm not making this up!)
If what you say is true, then it won't matter how I ship more units to you, unless I ask a family member to drive to Canada. And with CoVID-19, that family member would probably be told to f'k off and go home in the most polite manner possible, quite possibly in English and French simultaneously, because Canada. And I don't blame Canada one iota for that stance.
It also won't matter if or how I ship units to anyone else in Canada, either, then. We're just stuck waiting.
Sorry, Canadian friends! Hopefully soon!
In the meantime, I think I'll talk the spousal unit into making poutine in the near future. You know, as an offering to the shipping $DIETIES. Sure, that's the ticket. Totally. We've discovered Five Guys fries work really well for that, and there's a Five Guys across the street. We'll make this... sacrifice... of delicious poutine... in our gullets... to assuage the shipping $DIETIES that have tied up LTO Flash in international shipping limbo...
(Seriously, I now have a poutine craving. If you don't like poutine, then I'll take yours. Thanks.)
-
3
-
-
On 11/24/2020 at 5:06 PM, Kiwi said:I found a small Intybasic bug that I can't map at $c100. It doesn't show up in the .cfg file. I used to be able to map data to that segment at $c100 using older version of Intybasic. Small work around is to map at $c200. I'm not sure if I'm alone with the issue, I'm using the latest Intybasic version.
EDIT: I may be over in segment $A000-$BFFF, so that's why it's not mapping at $C100.
EDIT2: It been confirmed I was over that segment. It's now all fixed.Recent versions of AS1600 have a feature to help detect this problem. Have a look in jzintv/doc/utilities/as1600.txt, and look for ERR_IF_OVERWRITTEN. You can also use the as1600 command-line flag --err-if-overwritten (or -e for short) to turn this on. It'll cause AS1600 to throw an error if you accidentally assemble two things to the same address. I suspect it would have caught your section overflow.
------------------------------------------------------------------------------ ERR_IF_OVERWRITTEN expr Mark code as "not intended to be overwritten" FORCE_OVERWRITE expr Force code to be overwritten anyway ------------------------------------------------------------------------------ By default, AS1600 lets you assemble new code over addresses you've already assembled code into. That allows for some interesting tricks; however, most often this is really an error. The ERR_IF_OVERWRITTEN directive controls a flag that indicates whether the code that follows may be safely overwritten. 0 means "safe to overwrite", while 1 means "throw an error if overwritten." >>> Note: ERR_IF_OVERWRITTEN defaults to 0. You can change the default at >> the command line by adding the flag -e or --err-if-overwritten For example, if I wanted to fill some ROM with a fixed pattern, and then overwrite it with final code, I could do something like this: ERR_IF_OVERWRITTEN 0 ; About to write some filler data ORG $6000 REPEAT 4096 / 8 DECLE -1, -1, -1, -1, -1, -1, -1, -1 ENDR ERR_IF_OVERWRITTEN 1 ; Now overwrite it with real code ORG $6000 ; The following generates no errors or warnings. fun: PROC MVII #ISR, R0 MVO R0, $100 SWAP R0 MVO R0, $101 ;... ENDP ; This code, however, will trigger an error, because it's overwriting ; the code we just assembled at 'fun': ORG $6000 DECLE 12, 34 ; ERROR - ROM overwrite error on $6000 - $6001 The FORCE_OVERWRITE directive gives you the ability to forcibly overwrite code that was previously assembled with ERR_IF_OVERWRITTEN == 1. Revisiting the previous example: ERR_IF_OVERWRITTEN 1 ; Now overwrite it with real code ORG $6000 fun: PROC MVII #ISR, R0 MVO R0, $100 SWAP R0 MVO R0, $101 ;... ENDP ; With FORCE_OVERWRITE, this code now assembles without errors. FORCE_OVERWRITE 1 ORG $6000 DECLE 12, 34 The FORCE_OVERWRITE directive is meant for use in specialized macros that may wish to "back-patch" code that otherwise should have ERR_IF_OVERWRITTEN turned on. Use it sparingly. There is no way to query the current state of ERR_IF_OVERWRITTEN or FORCE_OVERWRITE. If you need to track that for some reason, wrap these in macros. Truth table: ERR_IF_OVERWRITTEN FORCE_OVERWRITE Result on an overwrite off off No error off ON No error ON off Report an error ON ON No error Note that ERR_IF_OVERWRITTEN tags current code to detect _future_ attempts to overwrite, while FORCE_OVERWRITE affects the code you're assembling right now. For example, this still generates an error, because the first DECLE was assembled with ERR_IF_OVERWRITTEN == 1: ERR_IF_OVERWRITTEN 1 ORG $6000 DECLE 1234 ERR_IF_OVERWRITTEN 0 ORG $6000 DECLE 3456 Conversely, this example does _not_ generate an error: ERR_IF_OVERWRITTEN 0 ORG $6000 DECLE 1234 ERR_IF_OVERWRITTEN 1 ORG $6000 DECLE 3456There's lots of neat stuff in the as1600.txt file. For example, you can add build dates to your program's metadata, so you know, just from looking at the .CFG file, when you built something.
I highly recommend every IntyBASIC programmer puts a line like this in their program:
ASM CFGVAR "build_date" = TODAY_STR_LOC("%Y-%m-%d %H:%M:%S %z")That'll add the current date and time into the CFG file (or .ROM file metadata). There's ways to get the current date/time as values as well, from within the assembler. That makes it possible to expose the values to the game, in case you want it to print that information on-screen, for example.
I find that's a huge help when beta-testing games. "Which version did you test?" "Uh, I don't know! It's this ROM. Which version is it?" *facepalm*
-
2
-
-
On 12/18/2020 at 4:16 AM, artrag said:Question: is there an efficient way to do a function doing this
YEvent:procedure 'YEvent(ys,ya) ' input ys,ya if (ya and 1) then yr = #Interaction(ys*2 + ((ya/2) and 1))/256 else yr = #Interaction(ys*2 + ((ya/2) and 1))and 255 end if endI did this:
DEF FN XEvent(s,a) = (#Interact(s*2 + ((a/2) and 1))/((a and 1)*255 + 1)) and 255
but it is way too slow for its purpose
On 12/18/2020 at 4:55 PM, nanochess said:You could implement an assembly language function and call it using USR YOURFUNC(ys,ya), R0 would get ys and R1 would get ya.
If it always uses ys and ya and writes to yr, it seems like it'd be faster to have a function that read those directly that you just CALL.
Something like this would work:
;YEvent:procedure 'YEvent(ys,ya) ; ' input ys,ya ; if (ya and 1) then ; yr = #Interaction(ys*2 + ((ya/2) and 1))/256 ; else ; yr = #Interaction(ys*2 + ((ya/2) and 1))and 255 ; end if ; end YEVENT PROC MVI var_YA, R0 ; 10 MVI var_YS, R1 ; 10 SARC R0 ; 6 C = YA and 1 GSWD R2 ; 6 stash it away in R2 SARC R0 ; 6 C = (YA / 2) and 1 RLC R1 ; 6 R1 = (YS*2 + ((YA/2) and 1)) ADDI #array_&INTERACTION, R1 ; 8 [email protected] R1, R0 ; 8 R0 = #Interaction(YS*2 + ((YA/2) and 1)) RSWD R2 ; 6 restore: C = YA and 1 BNC @@0 ; 7(9) If YA and 1 SWAP R0 ; 6 true: swap upper byte to lower @@0: MVO R0, var_YR ; 11 both: store lower byte. (No AND 255 needed.) JR R5 ; 7 return ENDP ;---- ; 97 cycles worst-caseIf you use USR instead, you'll want to swap the argument order so that ys ends up in R1. R0 can't be used for memory indexing. You will also need to put ANDI #$FF, R0 in place of MVO R0, var_YR, since there's no guarantee you'll store to 8-bit memory and slice off the upper 8 bits. The result would only be slightly slower (16 cycles), but it'll be larger by 6 words for every call you make to YEvent.
If you can change how you encode #Interaction and swap the two LSBs, you can eliminate the GSWD/RSWD pair and go faster. And if you invert the polarity for the if/else, you can save 2 more cycles in the "branch taken" case.
;YEvent:procedure 'YEvent(ys,ya) ; ' input ys,ya ; if (ya and 2) then ; yr = #Interaction(ys*2 + (ya and 1)) and 255 ; else ; yr = #Interaction(ys*2 + (ya and 1)) / 256 ; end if ; end YEVENT PROC MVI var_YA, R0 ; 10 MVI var_YS, R1 ; 10 SARC R0 ; 6 C = YA and 1 RLC R1 ; 6 R1 = (YS*2 + (YA and 1)) ADDI #array_&INTERACTION, R1 ; 8 [email protected] R1, R1 ; 8 R1 = #Interaction(YS*2 + ((YA/2) and 1)) SARC R0 ; 6 C = (YA and 2) <> 0 ADCR PC ; 7 skip SWAP if (YA and 2) <> 0 SWAP R0 ; 6 (YA and 2) = 0: swap upper byte to lower @@0: MVO R0, var_YR ; 11 both: store lower byte. (No AND 255 needed.) JR R5 ; 7 return ENDP ;---- ; 85 cycles worst-case-
1
-
-
4 hours ago, Steve Jones said:If everyone buys one who said they would so far, 36 out of 40 are gone, so only 4 more would be available in Canada for now.
We will have another 69 available in a couple weeks in the US. 18 more are headed to Thailand for final assembly, with half of those already earmarked for customers in Australia. That makes a total of 87 units in this last batch.
I will be able to send more to Canada at that time. If you think you might go beyond 36 orders in Canada, I can earmark some of the remaining 69. Just let me know.
I may have my mom ship them to someone else first, and have them ship into Canada from a different state. It's possible that after bouncing off Chicago, these headed towards the CF that is Detroit.
Or, it could be Canada Post itself, I which case it won't matter. I found this on the USPS service disruption page:
QuoteCanada
12-21-20Canada Post advises that it continues to experience significant disruptions to its activities because of exceptional precautionary measures implemented to protect the health and safety of its employees and Canadians, as well as persistent challenges relating to availability of transport links. Canada is experiencing a second wave of COVID-19 and all provinces remain in a state of emergency. A previously declared force majeure situation for all international letter-post, parcel-post and express mail service items will remain in effect until further notice.
Canada Post continues to follow the guidance and safety recommendations issued by the Public Health Agency of Canada, including physical distancing and self-quarantine for affected individuals. These measures have resulted in delays in mail processing, unprecedented levels of absenteeism among operational staff, and temporary facility closures due to COVID-19 outbreaks. It has not been possible to ensure on-time delivery since March 18 and this guarantee remains suspended until further notice.
Refer to the Canada Post website for more information.
What's amazing is that I have not opened general orders, really, and I am already down to my last dozens. I guess the word's out, though, and I may as well update the main website.
The limiting factor for this run was shells. I still have some boards. Even if I had more shells, I am running out of other artifacts, such as boxes. Manuals are also getting low, but I can have those reprinted easily.
-
1 hour ago, rietveld said:Any idea when the LTO will be available in Canada. I emailed the reseller January 3rd .
I have two large shipments headed to Canada, including one that I sent before Christmas, stuck in Chicago.
I have a feeling that if I had sent individual units to Canada, they'd fare no better.
I need to find out from @Steve Jones whether all of the units I have already sent him are accounted for on his waiting list. There's 40 LTO Flash units stuck in Chicago.
-
On 1/10/2021 at 1:07 AM, artrag said:Question related to coding the LTO:
Is there some contraindication in using the rom ranges
$0500 - $06FF RAM/ROM ok.
$0700 - $0CFF RAM/ROM ok if no Intellivoice.
$0D00 - $0FFF RAM/ROM ok.
with LTO ?
We are facing some hangs using these addressed when the rom is loaded in LTO and runs on real HW (no intellivoice or ECS plugged)
The problem does not occur in Jzintv emulator
In the current firmware, it looks like you can use $0500 - $0EFF.
$0F00 - $0FFF currently are taken by the UART and some status registers. For example, you can sense whether USB has power by reading $0F0F.
I suppose it shouldn't be hard to add a feature flag to turn UART on/off within the LUIGI format.
-
1
-
-
1 hour ago, palikka91 said:I contacted the french reseller. He asked my E-mail on thursday, havent heard him after that, but i assume im on his order list?
I would not assume that without positive confirmation from him. I think you're on his list, but only he can say for sure.
-
1 hour ago, Cruiser133 said:I am on your list brother but I ordered one from gdg so I could use PayPal. Please send my reserved copy to them or send them an extra and take me off your list. Thanks!!!
Thanks for letting me know. I will mark you as handled by GDG.
-
3 minutes ago, artrag said:Question related to coding the LTO:
Is there some contraindication in using the rom ranges
$0500 - $06FF RAM/ROM ok.
$0700 - $0CFF RAM/ROM ok if no Intellivoice.
$0D00 - $0FFF RAM/ROM ok.
with LTO ?
We are facing some hangs using these addressed when the rom is loaded in LTO and runs on real HW (no intellivoice or ECS plugged)
The problem does not occur in Jzintv emulator
I will be honest: I don't know off the top of my head. I think $0400 - $0FFF should work normally, but I need to look at the firmware to be sure. I know there are some limitations in lower memory, and $0F1x is where the UART lives.
-
1
-
-
9 minutes ago, SiLic0ne t0aD said:Cool, thanks for the heads up, Joe!
I might snag a regular one then, whenever the next batch goes up for grabs. 👍
Get on a waiting list now, rather than later, if you intend to purchase.
My "expressed interest" list, when I rolled everything up, totaled over 400 units. According to the experts in the Left Turn Only Advanced Mathematics Reseach Division™, 400 is larger than 320.
I am certain there's some double-counting in my interest list, as that number continues to drop as I align more names to AtariAge handles. That said, I know my resellers have sold a non-trivial number of units to folks who never contacted me. I think the two effects balance each other out.
We're on track to sell this entire run. So if you want one, get on a waiting list officially.
-
2
-
-
1 hour ago, SiLic0ne t0aD said:Will the SE be a big batch?
1 hour ago, wolfy62 said:Joe said he was making only 25 Special edition.
@wolfy62 is exactly correct. There will be exactly 25 Special Edition carts. Serial numbers 1 through 25.
If you want an additional LTO Flash!, and you're waiting hoping to get one of the 25 very limited Special Edition carts, you'll likely be disappointed, as there's zero guarantee you'll get one of the SE carts. There is no waiting list for the Special Edition. I will likely need to auction these somehow.
-
4
-
-
We have reached the first and second throttle points at essentially the same time: The next batch of carts going out will use up all shrinkwrapped copies, and the remaining "in-flight" confirmed orders eat up the rest of the initial 240.
All new orders (not counting folks who have already gotten confirmation from me) may see a ~3 week delay as we assemble the remaining 80 units from this batch. This includes sales through any resellers that would need me to ship more cartridges to them.
Demand has been phenomenal.
I'm in the process of making the next 80. I'm hoping we can stick to the 3 week number. Thank you for your patience.
-
2
-
-
Just a quick status update:
So far, I've shipped 168 LTO Flash! units, either to individuals or resellers. I have another 45-50 orders in flight (including check/money order sent my way), and a handful of paid but not-yet-shipped units.
I'm approaching our first "throttle point:" We had ~200 shrink-wrapped units ready to go. Shrink wrapping continues.
The second "throttle point" is right behind it: We had 240 units fully assembled, other than the shrink wrap for ~40, and with the checks that should be landing over the next couple days, we're a stone's throw away from 240.
I have more boards, shells, screws and boxes. When we hit that second throttle point, expect a 2-3wk delay before shipments resume.
I run out of plastic around 80 units past the second throttle point.
While I hadn't planned it this way, it seems LTO also means "Limited Time Only."
When this batch sells out (which seems like will happen by Valentine's Day), I guess we'll have to see what add'l demand there is, to see whether there's another batch. Don't worry, I am holding back the material I need for the Special Edition.
-
9
-
2
-
-
30 minutes ago, Intellivision**fan said:Never had any issues with PayPal. I don't like the fees as a seller. Yet as a buyer, my experience has been good. I've been protected. Now if PayPal doesn't understand or deny me purchasing the flash cartridge, well too bad. Believe me, they would hear my complaint.
All I know, very glad I got to purchase a copy of the lto flash cartridge. Plus very thankfull for +intvnut doing this run. Betting he's going to sell out again to.
Fun facts:
- Items prohibited by PayPal's AUP are ineligible for PayPal's Purchase Protection Program. So if you buy and the seller gets whacked before they ship, you don't necessarily get your refund.
- Sellers are on the hook for a minimum of $2,500 per violation, potentially. (It's up to them to go to court to argue it down. Yay, lawyers!)
Don't get me wrong: As a seller, I loved the convenience of PayPal. Their policy around flash carts in their AUP, and the fact that I'm pretty much only selling flash carts, leads me to where I am now.
I've already had PayPal freeze my account and screw up my checking account when they didn't understand "preorders" for Space Patrol.
The fees never bothered me. They aren't much different than what you'd pay to accept credit cards. It's that other stuff that kinda turns me off, at least for this product.
-
4
-
2 hours ago, carlsson said:At least in theory.
In my case, I have only one product with any real volume. And, I have messages on file where PayPal explicitly told me what they thought of it.
I'm pretty sure I'd make sore thumbs embarrassed at how I stick out.
-
2
-
-
17 hours ago, mr_me said:See the web site about direct orders.
FYI, folks that are on my list have been given a different URL that has more instructions. I wanted to make sure everyone who expressed interest the last year+ got a crack at it before I opened general ordering.
I believe I've captured everyone who contacted me over email. If you've contacted me only via AtariAge, I still need to make another pass through that. I'll try to catch you tomorrow. If it weren't for an 8:30AM meeting on my first day of work in 2021, I would do it tonight.
Between bulk shipments to redistributors and direct orders, the response has been amazing. 132 carts have gone out to resellers already, most of which are apparently accounted for. I have at least 72 "payment in flight" direct orders, of which 26 are already fully paid for. The rest are checks/money orders in the mail. That puts me at over 200 units already. There's a few more that are close to "payment in flight" beyond that.
There's a good chance I will need to pause sales if the demand keeps up, as we only have 240 manufactured at the moment. I do have more boards, boxes, etc. so I can still satisfy all of the potential orders I'm aware of. Still, I'm pretty sure I've sold more in the last few days than I sold in the entire last year that LTO Flash! was previously in print. Forgive me if I underestimated the pent up demand a little.
I knew I would sell 100 immediately. 200 in 3 or 4 days stunned me. I haven't seen that kind of rate ever in the life of LTO Flash!.
Given that situation, I would like to ask a huge favor: If you're ordering from one of my resellers, please let me know, so I can mark you as "fulfilled." I fully support my resellers. They're awesome. I just want to know I no longer need to hold a cart for you, as you've gotten a cart from them. That frees up a cart for someone else.
As for my US reseller: He asked me to wait until he'd received the (second) batch I'm sending him before announcing that he's a reseller. I wasn't trying to be cagey or anything. I was just honoring their request. The first batch I'd sent him, which was more than he was expecting, practically disappeared in under 24 hours.
The second batch is larger, naturally.
-
10
-
-
OK, I've sent out AtariAge messages to everyone I have on the AtariAge list, and email messages to everyone I have on my email list.
If you haven't received a message in one or both places and you think you're on the list, let me know. I was going to post an updated AtariAge list, but seeing as there were very few add'l folks adding themselves, it didn't seem worth it.
-
5
-
-
On 1/1/2021 at 10:13 PM, Intellivision**fan said:I can now see how the process of making these can take some time.
It may not sound like much, but the total assembly time for firmware programming (phase 1 and 2), testing (phase 1 and 2), cart notching, cart assembly, box gluing, box stuffing, shrink-wrapping, etc... ends up being around ~20 min/unit, easily. That's not counting add'l time for all the administrivia, shipping, etc. It's also a lot slower if you don't have the rhythm down.
—J
-
2
-
-
13 hours ago, palikka91 said:Are the resellers listed somewhere?
i live in europe, Finland, and was wondering wich is better, buy directly from you or the resellers?
It's probably better for you to buy within Europe.
-
In Thunder Castle, in the second stage, the "magical mouse" is drawn w/ two MOBs, but one of the MOBs cycles quickly between two colors, to create a shimmer effect, and a more brown color than the stock "brown":
I'll be honest: When I first saw that, I thought they were actually multiplexing a single MOB through the "eyes" and "body." When I dug into it, I discovered they aren't.
The other multi-color characters in the game (knights, wizards, demons) use two MOBs each. I think the dragon in the first level may use 4 MOBs, actually, to get the length.
You could, in theory, use a single MOB and cycle it quickly between two patterns and two colors to multiplex it. That said, modern TVs don't handle multiplexing well.
(BTW, the next time you play that game, when your knight gets caught by the bad guy, I have some lyrics to go with the theme that plays: "Damnable a--hole, Damnable a--hole, Damnable a--hole! F--k you, f--k you, f--k you, f--k you! Diiiiiiiie!" Those are lyrics ~9 year old me came up with over 35 years ago. Not exactly deep, but they fit the music, IMHO.)
In Space Patrol, I use 2 MOBs for the player's "tank", and I made creative use of pixel offsets to get more apparent resolution in the horizontal direction.
Space Patrol also did some interesting stuff with MOB multiplexing to minimize its negative effects. That's not really the point of this thread, though, so I won't bore folks with it.
-
3
-
-
I've added several people to the list, and have subtracted folks who've let me know they've already acquired units or will be acquiring them via one of the resellers. I'll check in again later, and post an updated list folks can cross-check against.
Also, a reminder: This is for the Regular Edition. I do not have a waiting list for Special Edition, nor do I have a specific timeline for it. I don't recommend holding out for Special Edition if you need a Regular Edition now.
Perhaps I can work out a trade-in program for folks who buy Special Edition later.
-
3
-
-
2 hours ago, DZ-Jay said:If you'd like, I can try reposting the images, since I seem to be the only one who can see them.
I've reposted everything with images as attachments. If those don't work, then the halibut! (╯°□°)╯︵ ┻━┻
-
2
-
-
5 minutes ago, koolmoecraig said:I really hope they aren't going through this post office Lol:
I legit have stuff that I bought off of ebay 3+ weeks ago that is tracking to this post office and then stopping.
Thankfully, they seem to have gone west, rather than east. The carts headed to @Steve Jones are currently in Chicago.
(While I happen to be in California, the carts are actually all in Michigan.)
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
IntyBASIC wide BITMAPs?
in Intellivision Programming
Posted
I thought about mentioning wgfx. I don't actually use IntyBASIC, though, so I don't know how well it does (or doesn't) mesh with IntyBASIC facilities. I think IntyBASIC's BITMAP was based on my original 8-pixel wide gfx_start/gfx/gfx_flush macros. So, perhaps wgfx_start/wgfx/wgfx_flush map nicely.
Also, a fun fact: The font shown in the wide_gfx.mac example is an early version of the "Narrow A" font used in LTO Flash's GUI. I had started developing the font for Super Pro Space Patrol (which never released).
LTO Flash has two narrow, proportionally spaced fonts, actually: "Narrow A" and "Narrow B". LTO Flash uses "Narrow B" when it can't fit a long name into the available space with "Narrow A".